* Re: kernel 2.4 vs 2.6 Traffic Controller performance
From: Eric Dumazet @ 2007-10-03 7:00 UTC (permalink / raw)
To: Sonny; +Cc: netdev
In-Reply-To: <9dbec86d0710022314o6db2b0baua6db543d52f312b6@mail.gmail.com>
Sonny a écrit :
> Hello
> This is a repost, there seems to have a misunderstanding before.
>
> I hope this is the right place to ask this. Does any know if there is a
> substantial difference in the performance of the traffic controller
> between kernel 2.4 and 2.6. We tested it using 1 iperf server and use
> 250 and 500 clients, altering the burst.
>
> This is the set-up:
> iperf client - router (w/ traffic controller) - iperf server
>
> We use the top command inside the router to check the idle time of our
> router to see this. The results we got from the 2.4 kernel shows
> around 65-70% idle time while the 2.6 shows
> 60-65% idle time. We tried to use MRTG and we're not getting any
> results either. We want to know if we could improve the bandwidth by
> upgrading the kernel, else we would have to get a new bandwidth
> manager. Have anyone performed a similar test or can suggest a better
> way to do this. Thanks in advance.
> -
Hi Sonny
I am not sure what you are asking here. 65-70% idle time (or 60-65%) is fine.
2.6 is also not very meaningfull, there are a lot of changes between 2.6.0 and
2.6.23 :)
Why should you upgrade kernel ?
What bandwidth do you handle ?
What kind of platform is it ? (a new kernel wont help much if its a real old
machine, or old NICs)
You seem to have some bandwidth problem but focus on cpu affairs...
^ permalink raw reply
* kernel 2.4 vs 2.6 Traffic Controller performance
From: Sonny @ 2007-10-03 6:14 UTC (permalink / raw)
To: netdev
Hello
This is a repost, there seems to have a misunderstanding before.
I hope this is the right place to ask this. Does any know if there is a
substantial difference in the performance of the traffic controller
between kernel 2.4 and 2.6. We tested it using 1 iperf server and use
250 and 500 clients, altering the burst.
This is the set-up:
iperf client - router (w/ traffic controller) - iperf server
We use the top command inside the router to check the idle time of our
router to see this. The results we got from the 2.4 kernel shows
around 65-70% idle time while the 2.6 shows
60-65% idle time. We tried to use MRTG and we're not getting any
results either. We want to know if we could improve the bandwidth by
upgrading the kernel, else we would have to get a new bandwidth
manager. Have anyone performed a similar test or can suggest a better
way to do this. Thanks in advance.
^ permalink raw reply
* Re: [PATCH] rtnl: Simplify ASSERT_RTNL
From: Herbert Xu @ 2007-10-03 6:06 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, oliver, Eric W. Biederman, linux-usb-devel, davem
In-Reply-To: <alpine.DEB.0.9999.0710021658100.12705@x2>
On Tue, Oct 02, 2007 at 05:29:11PM +0200, Patrick McHardy wrote:
>
> I think this doesn't completely fix it, when dev_unicast_add is
> interrupted by dev_mc_add before the unicast changes are performed,
> they will get committed in the dev_mc_add context, so we might still
> call change_flags with BH disabled. Taking the TX lock around the
> dev->uc_count and dev->uc_promisc checks and changes in __dev_set_rx_mode
> should fix this.
Good catch. Digging back in history it seems that you added
the change_rx_flags function so that the driver didn't have to
do it under TX lock, right?
The problem with this is that the stack can now call
change_rx_flags and set_multicast_list simultaneously
which presents a potential headache for the driver
author (if they were to use change_rx_flags).
It seems to me what we could do is in fact separate out the
part that adds the address and the part that syncs it with
hardware.
That way we can call the hardware from a process context later
and use the RTNL to guarantee that we only enter the driver
once.
So dev_mc_add would look like:
1) Hold some form of lock L.
2) Modify mc list A (a copy of the current mc list).
3) Drop lock.
4) Schedule an update to the hardware.
The update to the hardware would look lie:
1) Hold RTNL.
2) Hold lock L.
3) Copy list A to list B (B would be our current list).
4) Drop lock L.
5) Call the hardware.
6) Drop RTNL.
For compatibility, set_multicast_list would still be invoked
under the TX lock while set_rx_mode would do exactly the same
thing but would only hold the RTNL.
What do you think about this approach?
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
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
^ permalink raw reply
* [ofa-general] Re: [PATCH 2/3][NET_BATCH] net core use batching
From: Bill Fink @ 2007-10-03 5:29 UTC (permalink / raw)
To: hadi
Cc: randy.dunlap, Robert.Olsson, gaagaan, kumarkr,
peter.p.waskiewicz.jr, shemminger, johnpol, herbert, jeff,
rdreier, mcarlson, general, sri, jagana, mchan, netdev,
David Miller, tgraf, kaber
In-Reply-To: <1191331238.4353.59.camel@localhost>
On Tue, 02 Oct 2007, jamal wrote:
> On Tue, 2007-02-10 at 00:25 -0400, Bill Fink wrote:
>
> > One reason I ask, is that on an earlier set of alternative batching
> > xmit patches by Krishna Kumar, his performance testing showed a 30 %
> > performance hit for TCP for a single process and a size of 4 KB, and
> > a performance hit of 5 % for a single process and a size of 16 KB
> > (a size of 8 KB wasn't tested). Unfortunately I was too busy at the
> > time to inquire further about it, but it would be a major potential
> > concern for me in my 10-GigE network testing with 9000-byte jumbo
> > frames. Of course the single process and 4 KB or larger size was
> > the only case that showed a significant performance hit in Krishna
> > Kumar's latest reported test results, so it might be acceptable to
> > just have a switch to disable the batching feature for that specific
> > usage scenario. So it would be useful to know if your xmit batching
> > changes would have similar issues.
>
> There were many times while testing that i noticed inconsistencies and
> in each case when i analysed[1], i found it to be due to some variable
> other than batching which needed some resolving, always via some
> parametrization or other. I suspect what KK posted is in the same class.
> To give you an example, with UDP, batching was giving worse results at
> around 256B compared to 64B or 512B; investigating i found that the
> receiver just wasnt able to keep up and the udp layer dropped a lot of
> packets so both iperf and netperf reported bad numbers. Fixing the
> receiver ended up with consistency coming back. On why 256B was the one
> that overwhelmed the receiver more than 64B(which sent more pps)? On
> some limited investigation, it seemed to me to be the effect of the
> choice of the tg3 driver's default tx mitigation parameters as well tx
> ring size; which is something i plan to revisit (but neutralizing it
> helps me focus on just batching). In the end i dropped both netperf and
> iperf for similar reasons and wrote my own app. What i am trying to
> achieve is demonstrate if batching is a GoodThing. In experimentation
> like this, it is extremely valuable to reduce the variables. Batching
> may expose other orthogonal issues - those need to be resolved or fixed
> as they are found. I hope that sounds sensible.
It does sound sensible. My own decidedly non-expert speculation
was that the big 30 % performance hit right at 4 KB may be related
to memory allocation issues or having to split the skb across
multiple 4 KB pages. And perhaps it only affected the single
process case because with multiple processes lock contention may
be a bigger issue and the xmit batching changes would presumably
help with that. I am admittedly a novice when it comes to the
detailed internals of TCP/skb processing, although I have been
slowly slogging my way through parts of the TCP kernel code to
try and get a better understanding, so I don't know if these
thoughts have any merit.
BTW does anyone know of a good book they would recommend that has
substantial coverage of the Linux kernel TCP code, that's fairly
up-to-date and gives both an overall view of the code and packet
flow as well as details on individual functions and algorithms,
and hopefully covers basic issues like locking and synchronization,
concurrency of different parts of the stack, and memory allocation.
I have several books already on Linux kernel and networking internals,
but they seem to only cover the IP (and perhaps UDP) portions of the
network stack, and none have more than a cursory reference to TCP.
The most useful documentation on the Linux TCP stack that I have
found thus far is some of Dave Miller's excellent web pages and
a few other web references, but overall it seems fairly skimpy
for such an important part of the Linux network code.
> Back to the >=9K packet size you raise above:
> I dont have a 10Gige card so iam theorizing. Given that theres an
> observed benefit to batching for a saturated link with "smaller" packets
> (in my results "small" is anything below 256B which maps to about
> 380Kpps anything above that seems to approach wire speed and the link is
> the bottleneck); then i theorize that 10Gige with 9K jumbo frames if
> already achieving wire rate, should continue to do so. And sizes below
> that will see improvements if they were not already hitting wire rate.
> So i would say that with 10G NICS, there will be more observed
> improvements with batching with apps that do bulk transfers (assuming
> those apps are not seeing wire speed already). Note that this hasnt been
> quiet the case even with TSO given the bottlenecks in the Linux
> receivers that J Heffner put nicely in a response to some results you
> posted - but that exposes an issue with Linux receivers rather than TSO.
It would be good to see some empirical evidence that there aren't
any unforeseen gotchas for larger packet sizes, that at least the
same level of performance can be obtained with no greater CPU
utilization.
> > Also for your xmit batching changes, I think it would be good to see
> > performance comparisons for TCP and IP forwarding in addition to your
> > UDP pktgen tests,
>
> That is not pktgen - it is a udp app running in process context
> utilizing all 4CPUs to send traffic. pktgen bypasses the stack entirely
> and has its own merits in proving that batching infact is a GoodThing
> even if it is just for traffic generation ;->
>
> > including various packet sizes up to and including
> > 9000-byte jumbo frames.
>
> I will do TCP and forwarding tests in the near future.
Looking forward to it.
> cheers,
> jamal
>
> [1] On average i spend 10x more time performance testing and analysing
> results than writting code.
As you have written previously, and I heartily agree with, this is a
very good practice for developing performance enhancement patches.
-Thanks
-Bill
^ permalink raw reply
* Re: [PATCH] sky2: jumbo frame regression fix
From: Stephen Hemminger @ 2007-10-03 4:59 UTC (permalink / raw)
To: pomac; +Cc: Jeff Garzik, Linux-kernel, netdev
In-Reply-To: <1191375274.26233.17.camel@localhost>
On Wed, 03 Oct 2007 03:34:34 +0200
Ian Kumlien <pomac@vapor.com> wrote:
> On tis, 2007-10-02 at 18:02 -0700, Stephen Hemminger wrote:
> > Remove unneeded check that caused problems with jumbo frame sizes.
> > The check was recently added and is wrong.
> > When using jumbo frames the sky2 driver does fragmentation, so
> > rx_data_size is less than mtu.
>
> Confirmed working.
>
> Now running with 9k mtu with no errors, =)
>
> It also seems that the FIFO bug was the one that affected me before,
> damn odd race that one.
Does the workaround (forced reset work). Ian, you are the first person to
report triggering it. I haven't found a way to make it happen.
What combination of flow control and speeds are you using?
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: [PATCH] sky2: jumbo frame regression fix
From: Jeff Garzik @ 2007-10-03 4:58 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: pomac, Linux-kernel, netdev
In-Reply-To: <20071002215316.0faa7676@freepuppy.rosehill>
Stephen Hemminger wrote:
> On Tue, 02 Oct 2007 21:07:22 -0400
> Jeff Garzik <jgarzik@pobox.com> wrote:
>
>> Stephen Hemminger wrote:
>>> Remove unneeded check that caused problems with jumbo frame sizes.
>>> The check was recently added and is wrong.
>>> When using jumbo frames the sky2 driver does fragmentation, so
>>> rx_data_size is less than mtu.
>>>
>>> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
>>>
>>> --- a/drivers/net/sky2.c 2007-10-02 17:56:31.000000000 -0700
>>> +++ b/drivers/net/sky2.c 2007-10-02 17:58:56.000000000 -0700
>>> @@ -2163,9 +2163,6 @@ static struct sk_buff *sky2_receive(stru
>>> sky2->rx_next = (sky2->rx_next + 1) % sky2->rx_pending;
>>> prefetch(sky2->rx_ring + sky2->rx_next);
>>>
>>> - if (length < ETH_ZLEN || length > sky2->rx_data_size)
>>> - goto len_error;
>>> -
>> 2.6.23? 2.6.24? enquiring minds want to know...
>
> 2.6.23, since it is a regression
You can have regressions in behavior in net-2.6.24.git, too. _Please_
be specific about where you want your patches to go. Thanks.
Jeff
^ permalink raw reply
* Re: [PATCH] sky2: jumbo frame regression fix
From: Stephen Hemminger @ 2007-10-03 4:53 UTC (permalink / raw)
To: Jeff Garzik; +Cc: pomac, Linux-kernel, netdev
In-Reply-To: <4702EB4A.4000208@pobox.com>
On Tue, 02 Oct 2007 21:07:22 -0400
Jeff Garzik <jgarzik@pobox.com> wrote:
> Stephen Hemminger wrote:
> > Remove unneeded check that caused problems with jumbo frame sizes.
> > The check was recently added and is wrong.
> > When using jumbo frames the sky2 driver does fragmentation, so
> > rx_data_size is less than mtu.
> >
> > Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
> >
> > --- a/drivers/net/sky2.c 2007-10-02 17:56:31.000000000 -0700
> > +++ b/drivers/net/sky2.c 2007-10-02 17:58:56.000000000 -0700
> > @@ -2163,9 +2163,6 @@ static struct sk_buff *sky2_receive(stru
> > sky2->rx_next = (sky2->rx_next + 1) % sky2->rx_pending;
> > prefetch(sky2->rx_ring + sky2->rx_next);
> >
> > - if (length < ETH_ZLEN || length > sky2->rx_data_size)
> > - goto len_error;
> > -
>
> 2.6.23? 2.6.24? enquiring minds want to know...
2.6.23, since it is a regression
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: Please pull 'upstream-davem' branch of wireless-2.6
From: David Miller @ 2007-10-03 2:01 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20071003012552.GE29361-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Tue, 2 Oct 2007 21:25:52 -0400
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream-davem
This doesn't pull cleanly.
Probably you used a recently cloned Linus tree, pulled
net-2.6.24 into that (and resolved the conflicts), and
then put your patches in.
Please don't do it like that, I don't want to pull from
a tree that has linus vs. net-2.6.24 conflict handling
in it. That's why I usually rebase frequently, to minimize
that as much as is humanly possible.
What you can do is figure out what linus's HEAD was at the last rebase
(basically 'origin' or parent of net-2.6.24), clone that then pull in
net-2.6.24, then add your patches.
That way I can always do a clean pull.
My pull from Jeff today was very clean, for example.
I'll add these wireless bits by hand as patches.
Thanks John.
^ permalink raw reply
* Re: [PATCH] baycom epp header ops
From: David Miller @ 2007-10-03 1:48 UTC (permalink / raw)
To: shemminger; +Cc: akpm, netdev
In-Reply-To: <20071002174103.4303b9dc@oldman>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Tue, 2 Oct 2007 17:41:03 -0700
> Update baycom epp driver for new header ops in net-2.6.24
>
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Applied, thanks Stephen.
^ permalink raw reply
* Re: Please pull 'upstream-davem' branch of wireless-2.6
From: John W. Linville @ 2007-10-03 1:45 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20071003012552.GE29361-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Of course, these are intended for 2.6.24. Also, I forgot to mention
that the individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/upstream-davem/
I also preserved the net-2.6.24 commit I based from as 'master-davem'
in case you need it for reference.
Hth!
John
On Tue, Oct 02, 2007 at 09:25:52PM -0400, John W. Linville wrote:
> The following changes since commit d3adbde754a9ae7a6f87612055cb20db856f0721:
> Ilpo Järvinen (1):
> [TCP]: Wrap-safed reordering detection FRTO check
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream-davem
>
> Daniel Drake (1):
> hostap: set netdev type before registering AP interface
>
> Johannes Berg (9):
> mac80211: add "invalid" interface type
> mac80211: remove management interface
> mac80211: move sta_process rx handler later
> mac80211: consolidate decryption more
> mac80211: use RX_FLAG_DECRYPTED for sw decrypted as well
> mac80211: remove ALG_NONE
> mac80211: improve radiotap injection
> mac80211: make userspace-mlme a per-interface setting
> mac80211: implement cfg80211's change_interface hook
>
> Michael Buesch (9):
> rfkill: Add support for an rfkill LED.
> rfkill: Add support for hardware-only rfkill buttons
> b43: LED triggers support
> b43: RF-kill support
> b43: Use input-polldev for the rfkill switch
> b43: Rewrite pwork locking policy.
> mac80211: Check open_count before calling config callback.
> mac80211: Add association LED trigger
> mac80211: Update beacon_update callback documentation
>
> Tomas Winkler (1):
> mac80211: add sta_notify callback
>
> Ulrich Kunitz (1):
> zd1211rw: Removed zd_util.c and zd_util.h
>
> Documentation/networking/mac80211-injection.txt | 32 ++-
> drivers/net/wireless/adm8211.c | 8 +-
> drivers/net/wireless/b43/Kconfig | 12 +
> drivers/net/wireless/b43/Makefile | 5 +-
> drivers/net/wireless/b43/b43.h | 11 +-
> drivers/net/wireless/b43/leds.c | 399 ++++++++++-------------
> drivers/net/wireless/b43/leds.h | 63 ++--
> drivers/net/wireless/b43/main.c | 205 ++++--------
> drivers/net/wireless/b43/phy.c | 13 +-
> drivers/net/wireless/b43/phy.h | 2 +-
> drivers/net/wireless/b43/rfkill.c | 184 +++++++++++
> drivers/net/wireless/b43/rfkill.h | 58 ++++
> drivers/net/wireless/hostap/hostap.h | 2 +-
> drivers/net/wireless/hostap/hostap_hw.c | 2 +-
> drivers/net/wireless/hostap/hostap_main.c | 19 +-
> drivers/net/wireless/iwlwifi/iwl3945-base.c | 4 -
> drivers/net/wireless/iwlwifi/iwl4965-base.c | 4 -
> drivers/net/wireless/p54common.c | 4 +-
> drivers/net/wireless/p54pci.c | 4 +-
> drivers/net/wireless/rt2x00/rt2x00.h | 2 +-
> drivers/net/wireless/zd1211rw/Makefile | 2 +-
> drivers/net/wireless/zd1211rw/zd_chip.c | 1 -
> drivers/net/wireless/zd1211rw/zd_mac.c | 4 +-
> drivers/net/wireless/zd1211rw/zd_usb.c | 1 -
> drivers/net/wireless/zd1211rw/zd_util.c | 82 -----
> drivers/net/wireless/zd1211rw/zd_util.h | 29 --
> include/linux/rfkill.h | 24 ++
> include/net/mac80211.h | 46 +++-
> net/mac80211/cfg.c | 75 ++++-
> net/mac80211/ieee80211.c | 189 +-----------
> net/mac80211/ieee80211_i.h | 17 +-
> net/mac80211/ieee80211_iface.c | 68 +----
> net/mac80211/ieee80211_ioctl.c | 31 +-
> net/mac80211/ieee80211_led.c | 67 +++-
> net/mac80211/ieee80211_led.h | 6 +
> net/mac80211/ieee80211_rate.c | 3 +-
> net/mac80211/ieee80211_rate.h | 2 -
> net/mac80211/ieee80211_sta.c | 7 +-
> net/mac80211/key.c | 1 -
> net/mac80211/rx.c | 122 +++-----
> net/mac80211/sta_info.c | 13 +-
> net/mac80211/tx.c | 211 ++++++------
> net/mac80211/wme.c | 10 +-
> net/rfkill/Kconfig | 7 +
> net/rfkill/rfkill.c | 49 +++-
> 45 files changed, 1022 insertions(+), 1078 deletions(-)
> create mode 100644 drivers/net/wireless/b43/rfkill.c
> create mode 100644 drivers/net/wireless/b43/rfkill.h
> delete mode 100644 drivers/net/wireless/zd1211rw/zd_util.c
> delete mode 100644 drivers/net/wireless/zd1211rw/zd_util.h
>
> Omnibus patch attached as upstream-davem.patch.bz2
--
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
^ permalink raw reply
* Please pull 'upstream-davem' branch of wireless-2.6
From: John W. Linville @ 2007-10-03 1:25 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-wireless
[-- Attachment #1: Type: text/plain, Size: 4515 bytes --]
The following changes since commit d3adbde754a9ae7a6f87612055cb20db856f0721:
Ilpo Järvinen (1):
[TCP]: Wrap-safed reordering detection FRTO check
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream-davem
Daniel Drake (1):
hostap: set netdev type before registering AP interface
Johannes Berg (9):
mac80211: add "invalid" interface type
mac80211: remove management interface
mac80211: move sta_process rx handler later
mac80211: consolidate decryption more
mac80211: use RX_FLAG_DECRYPTED for sw decrypted as well
mac80211: remove ALG_NONE
mac80211: improve radiotap injection
mac80211: make userspace-mlme a per-interface setting
mac80211: implement cfg80211's change_interface hook
Michael Buesch (9):
rfkill: Add support for an rfkill LED.
rfkill: Add support for hardware-only rfkill buttons
b43: LED triggers support
b43: RF-kill support
b43: Use input-polldev for the rfkill switch
b43: Rewrite pwork locking policy.
mac80211: Check open_count before calling config callback.
mac80211: Add association LED trigger
mac80211: Update beacon_update callback documentation
Tomas Winkler (1):
mac80211: add sta_notify callback
Ulrich Kunitz (1):
zd1211rw: Removed zd_util.c and zd_util.h
Documentation/networking/mac80211-injection.txt | 32 ++-
drivers/net/wireless/adm8211.c | 8 +-
drivers/net/wireless/b43/Kconfig | 12 +
drivers/net/wireless/b43/Makefile | 5 +-
drivers/net/wireless/b43/b43.h | 11 +-
drivers/net/wireless/b43/leds.c | 399 ++++++++++-------------
drivers/net/wireless/b43/leds.h | 63 ++--
drivers/net/wireless/b43/main.c | 205 ++++--------
drivers/net/wireless/b43/phy.c | 13 +-
drivers/net/wireless/b43/phy.h | 2 +-
drivers/net/wireless/b43/rfkill.c | 184 +++++++++++
drivers/net/wireless/b43/rfkill.h | 58 ++++
drivers/net/wireless/hostap/hostap.h | 2 +-
drivers/net/wireless/hostap/hostap_hw.c | 2 +-
drivers/net/wireless/hostap/hostap_main.c | 19 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 4 -
drivers/net/wireless/iwlwifi/iwl4965-base.c | 4 -
drivers/net/wireless/p54common.c | 4 +-
drivers/net/wireless/p54pci.c | 4 +-
drivers/net/wireless/rt2x00/rt2x00.h | 2 +-
drivers/net/wireless/zd1211rw/Makefile | 2 +-
drivers/net/wireless/zd1211rw/zd_chip.c | 1 -
drivers/net/wireless/zd1211rw/zd_mac.c | 4 +-
drivers/net/wireless/zd1211rw/zd_usb.c | 1 -
drivers/net/wireless/zd1211rw/zd_util.c | 82 -----
drivers/net/wireless/zd1211rw/zd_util.h | 29 --
include/linux/rfkill.h | 24 ++
include/net/mac80211.h | 46 +++-
net/mac80211/cfg.c | 75 ++++-
net/mac80211/ieee80211.c | 189 +-----------
net/mac80211/ieee80211_i.h | 17 +-
net/mac80211/ieee80211_iface.c | 68 +----
net/mac80211/ieee80211_ioctl.c | 31 +-
net/mac80211/ieee80211_led.c | 67 +++-
net/mac80211/ieee80211_led.h | 6 +
net/mac80211/ieee80211_rate.c | 3 +-
net/mac80211/ieee80211_rate.h | 2 -
net/mac80211/ieee80211_sta.c | 7 +-
net/mac80211/key.c | 1 -
net/mac80211/rx.c | 122 +++-----
net/mac80211/sta_info.c | 13 +-
net/mac80211/tx.c | 211 ++++++------
net/mac80211/wme.c | 10 +-
net/rfkill/Kconfig | 7 +
net/rfkill/rfkill.c | 49 +++-
45 files changed, 1022 insertions(+), 1078 deletions(-)
create mode 100644 drivers/net/wireless/b43/rfkill.c
create mode 100644 drivers/net/wireless/b43/rfkill.h
delete mode 100644 drivers/net/wireless/zd1211rw/zd_util.c
delete mode 100644 drivers/net/wireless/zd1211rw/zd_util.h
Omnibus patch attached as upstream-davem.patch.bz2
--
John W. Linville
linville@tuxdriver.com
[-- Attachment #2: upstream-davem.patch.bz2 --]
[-- Type: application/x-bzip2, Size: 26503 bytes --]
^ permalink raw reply
* Please pull 'fixes-jgarzik' branch of wireless-2.6
From: John W. Linville @ 2007-10-03 1:20 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-wireless
The following changes since commit 3146b39c185f8a436d430132457e84fa1d8f8208:
Linus Torvalds (1):
Linux 2.6.23-rc9
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git fixes-jgarzik
Joe Perches (1):
bcm43xx: Correct printk with PFX before KERN_
Richard Knutsson (1):
softmac: Fix compiler-warning
drivers/net/wireless/bcm43xx/bcm43xx_wx.c | 2 +-
net/ieee80211/softmac/ieee80211softmac_wx.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
index d6d9413..6acfdc4 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
@@ -444,7 +444,7 @@ static int bcm43xx_wx_set_xmitpower(struct net_device *net_dev,
u16 maxpower;
if ((data->txpower.flags & IW_TXPOW_TYPE) != IW_TXPOW_DBM) {
- printk(PFX KERN_ERR "TX power not in dBm.\n");
+ printk(KERN_ERR PFX "TX power not in dBm.\n");
return -EOPNOTSUPP;
}
diff --git a/net/ieee80211/softmac/ieee80211softmac_wx.c b/net/ieee80211/softmac/ieee80211softmac_wx.c
index 442b987..5742dc8 100644
--- a/net/ieee80211/softmac/ieee80211softmac_wx.c
+++ b/net/ieee80211/softmac/ieee80211softmac_wx.c
@@ -114,7 +114,7 @@ check_assoc_again:
sm->associnfo.associating = 1;
/* queue lower level code to do work (if necessary) */
schedule_delayed_work(&sm->associnfo.work, 0);
-out:
+
mutex_unlock(&sm->associnfo.mutex);
return 0;
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply related
* Re: [PATCH] sky2: jumbo frame regression fix
From: Ian Kumlien @ 2007-10-03 1:34 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jeff Garzik, Linux-kernel, netdev
In-Reply-To: <20071002180209.47c350a3@freepuppy.rosehill>
[-- Attachment #1: Type: text/plain, Size: 1411 bytes --]
On tis, 2007-10-02 at 18:02 -0700, Stephen Hemminger wrote:
> Remove unneeded check that caused problems with jumbo frame sizes.
> The check was recently added and is wrong.
> When using jumbo frames the sky2 driver does fragmentation, so
> rx_data_size is less than mtu.
Confirmed working.
Now running with 9k mtu with no errors, =)
It also seems that the FIFO bug was the one that affected me before,
damn odd race that one.
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Tested-by: Ian Kumlien <pomac@vapor.com>
(if that tag exists now)
Btw, Sorry but all mail directly to you will be blocked. I have yet to
fix the relaying properly with isp:s blocking port 25 etc so for some of
you this mail will only show up on the ML.
> --- a/drivers/net/sky2.c 2007-10-02 17:56:31.000000000 -0700
> +++ b/drivers/net/sky2.c 2007-10-02 17:58:56.000000000 -0700
> @@ -2163,9 +2163,6 @@ static struct sk_buff *sky2_receive(stru
> sky2->rx_next = (sky2->rx_next + 1) % sky2->rx_pending;
> prefetch(sky2->rx_ring + sky2->rx_next);
>
> - if (length < ETH_ZLEN || length > sky2->rx_data_size)
> - goto len_error;
> -
> /* This chip has hardware problems that generates bogus status.
> * So do only marginal checking and expect higher level protocols
> * to handle crap frames.
--
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] sky2: jumbo frame regression fix
From: Jeff Garzik @ 2007-10-03 1:07 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: pomac, Linux-kernel, netdev
In-Reply-To: <20071002180209.47c350a3@freepuppy.rosehill>
Stephen Hemminger wrote:
> Remove unneeded check that caused problems with jumbo frame sizes.
> The check was recently added and is wrong.
> When using jumbo frames the sky2 driver does fragmentation, so
> rx_data_size is less than mtu.
>
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
>
> --- a/drivers/net/sky2.c 2007-10-02 17:56:31.000000000 -0700
> +++ b/drivers/net/sky2.c 2007-10-02 17:58:56.000000000 -0700
> @@ -2163,9 +2163,6 @@ static struct sk_buff *sky2_receive(stru
> sky2->rx_next = (sky2->rx_next + 1) % sky2->rx_pending;
> prefetch(sky2->rx_ring + sky2->rx_next);
>
> - if (length < ETH_ZLEN || length > sky2->rx_data_size)
> - goto len_error;
> -
2.6.23? 2.6.24? enquiring minds want to know...
^ permalink raw reply
* [PATCH] sky2: jumbo frame regression fix
From: Stephen Hemminger @ 2007-10-03 1:02 UTC (permalink / raw)
To: pomac, Jeff Garzik; +Cc: Linux-kernel, netdev
In-Reply-To: <1191372129.26233.12.camel@localhost>
Remove unneeded check that caused problems with jumbo frame sizes.
The check was recently added and is wrong.
When using jumbo frames the sky2 driver does fragmentation, so
rx_data_size is less than mtu.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
--- a/drivers/net/sky2.c 2007-10-02 17:56:31.000000000 -0700
+++ b/drivers/net/sky2.c 2007-10-02 17:58:56.000000000 -0700
@@ -2163,9 +2163,6 @@ static struct sk_buff *sky2_receive(stru
sky2->rx_next = (sky2->rx_next + 1) % sky2->rx_pending;
prefetch(sky2->rx_ring + sky2->rx_next);
- if (length < ETH_ZLEN || length > sky2->rx_data_size)
- goto len_error;
-
/* This chip has hardware problems that generates bogus status.
* So do only marginal checking and expect higher level protocols
* to handle crap frames.
^ permalink raw reply
* [PATCH] baycom epp header ops
From: Stephen Hemminger @ 2007-10-03 0:41 UTC (permalink / raw)
To: akpm; +Cc: davem, netdev, akpm
In-Reply-To: <200710022104.l92L4cuE022227@imap1.linux-foundation.org>
Update baycom epp driver for new header ops in net-2.6.24
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
---
drivers/net/hamradio/baycom_epp.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/hamradio/baycom_epp.c b/drivers/net/hamradio/baycom_epp.c
index 355c6cf..1a5a75a 100644
--- a/drivers/net/hamradio/baycom_epp.c
+++ b/drivers/net/hamradio/baycom_epp.c
@@ -1159,8 +1159,7 @@ static void baycom_probe(struct net_device *dev)
/* Fill in the fields of the device structure */
bc->skb = NULL;
- dev->hard_header = ax25_hard_header;
- dev->rebuild_header = ax25_rebuild_header;
+ dev->header_ops = &ax25_header_ops;
dev->set_mac_address = baycom_set_mac_address;
dev->type = ARPHRD_AX25; /* AF_AX25 device */
--
1.5.2.5
^ permalink raw reply related
* Kernel 2.4 vs 2.6 Traffic Controller Performance
From: Sonny @ 2007-10-03 0:30 UTC (permalink / raw)
To: netdev
Hello
I hope this is the right place to ask this.Does any know if there is a
substantial difference in the performance of the traffic controller
between kernel 2.4 and 2.6. We tested it using 1 iperf server and use
250 and 500 clients, altering the burst. We use the top command to
check the idle time of our router to see this. The results we got from
the 2.4 kernel shows around 65-70% idle time while the 2.6 shows
60-65% idle time. We tried to use MRTG and we're not getting any
results either. We want to know if we could improve the bandwidth by
upgrading the kernel, else we would have to get a new bandwidth
manager. Could anyone have the similar test regarding this or suggest
a better way to do this. Thanks in advance.
^ permalink raw reply
* Re: [git patches] net driver updates
From: David Miller @ 2007-10-02 23:38 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-kernel
In-Reply-To: <20071002174150.GA29780@havoc.gtf.org>
From: Jeff Garzik <jeff@garzik.org>
Date: Tue, 2 Oct 2007 13:41:50 -0400
> Please pull from the 'upstream' branch of
> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream
Pulled and pushed back out to net-2.6.24, thanks Jeff!
^ permalink raw reply
* Re: [PATCH 2.6.24 3/3][BNX2]: Update version to 1.6.6.
From: Jeff Garzik @ 2007-10-02 23:29 UTC (permalink / raw)
To: Michael Chan; +Cc: davem, netdev
In-Reply-To: <1191371046.5961.33.camel@dell>
Michael Chan wrote:
> [BNX2]: Update version to 1.6.6.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
ACK patches 1-3
^ permalink raw reply
* Re: [PATCH 2.6.24 3/3][BNX2]: Update version to 1.6.6.
From: David Miller @ 2007-10-02 23:28 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1191371046.5961.33.camel@dell>
From: "Michael Chan" <mchan@broadcom.com>
Date: Tue, 02 Oct 2007 17:24:06 -0700
> [BNX2]: Update version to 1.6.6.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Also applied to net-2.6.24, thanks!
^ permalink raw reply
* Re: [PATCH 2.6.24 2/3][BNX2]: Optimize firmware loading.
From: David Miller @ 2007-10-02 23:27 UTC (permalink / raw)
To: mchan; +Cc: netdev, vda.linux
In-Reply-To: <1191371023.5961.32.camel@dell>
From: "Michael Chan" <mchan@broadcom.com>
Date: Tue, 02 Oct 2007 17:23:43 -0700
> [BNX2]: Optimize firmware loading.
>
> This is a follow up to the patches from Denys Vlasenkos
> <vda.linux@googlemail.com> to further optimize firmware loading.
>
> 1. In bnx2_init_cpus(), we allocate memory for decompression once
> and use it repeatedly instead of doing this for every firmware image.
>
> 2. We eliminate the BSS and SBSS firmware sections in bnx2_fw*.h since
> these are always zeros.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied, thanks for following up on this Michael.
^ permalink raw reply
* Re: [PATCH 2.6.24 1/3][BNX2]: Add missing napi_disable() in bnx2_close().
From: David Miller @ 2007-10-02 23:27 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1191370989.5961.31.camel@dell>
From: "Michael Chan" <mchan@broadcom.com>
Date: Tue, 02 Oct 2007 17:23:09 -0700
> [BNX2]: Add missing napi_disable() in bnx2_close().
>
> bnx2_close() -> bnx2_netif_stop() will not call napi_disable() because
> the netif_state is not running in bnx2_close(). To avoid confusion,
> we change it to disable interrupt and napi directly in bnx2_close().
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied to net-2.6.24
^ permalink raw reply
* [PATCH 2.6.24 3/3][BNX2]: Update version to 1.6.6.
From: Michael Chan @ 2007-10-03 0:24 UTC (permalink / raw)
To: davem; +Cc: netdev
[BNX2]: Update version to 1.6.6.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index c50e4c8..db14f35 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -56,8 +56,8 @@
#define DRV_MODULE_NAME "bnx2"
#define PFX DRV_MODULE_NAME ": "
-#define DRV_MODULE_VERSION "1.6.5"
-#define DRV_MODULE_RELDATE "September 20, 2007"
+#define DRV_MODULE_VERSION "1.6.6"
+#define DRV_MODULE_RELDATE "October 2, 2007"
#define RUN_AT(x) (jiffies + (x))
^ permalink raw reply related
* [PATCH 2.6.24 2/3][BNX2]: Optimize firmware loading.
From: Michael Chan @ 2007-10-03 0:23 UTC (permalink / raw)
To: davem; +Cc: netdev, vda.linux
[BNX2]: Optimize firmware loading.
This is a follow up to the patches from Denys Vlasenkos
<vda.linux@googlemail.com> to further optimize firmware loading.
1. In bnx2_init_cpus(), we allocate memory for decompression once
and use it repeatedly instead of doing this for every firmware image.
2. We eliminate the BSS and SBSS firmware sections in bnx2_fw*.h since
these are always zeros.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 4887c31..c50e4c8 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -2810,21 +2810,16 @@ load_cpu_fw(struct bnx2 *bp, struct cpu_reg *cpu_reg, struct fw_info *fw)
/* Load the Text area. */
offset = cpu_reg->spad_base + (fw->text_addr - cpu_reg->mips_view_base);
if (fw->gz_text) {
- u32 *text;
int j;
- text = vmalloc(FW_BUF_SIZE);
- if (!text)
- return -ENOMEM;
- rc = zlib_inflate_blob(text, FW_BUF_SIZE, fw->gz_text, fw->gz_text_len);
- if (rc < 0) {
- vfree(text);
+ rc = zlib_inflate_blob(fw->text, FW_BUF_SIZE, fw->gz_text,
+ fw->gz_text_len);
+ if (rc < 0)
return rc;
- }
+
for (j = 0; j < (fw->text_len / 4); j++, offset += 4) {
- REG_WR_IND(bp, offset, cpu_to_le32(text[j]));
+ REG_WR_IND(bp, offset, cpu_to_le32(fw->text[j]));
}
- vfree(text);
}
/* Load the Data area. */
@@ -2839,21 +2834,21 @@ load_cpu_fw(struct bnx2 *bp, struct cpu_reg *cpu_reg, struct fw_info *fw)
/* Load the SBSS area. */
offset = cpu_reg->spad_base + (fw->sbss_addr - cpu_reg->mips_view_base);
- if (fw->sbss) {
+ if (fw->sbss_len) {
int j;
for (j = 0; j < (fw->sbss_len / 4); j++, offset += 4) {
- REG_WR_IND(bp, offset, fw->sbss[j]);
+ REG_WR_IND(bp, offset, 0);
}
}
/* Load the BSS area. */
offset = cpu_reg->spad_base + (fw->bss_addr - cpu_reg->mips_view_base);
- if (fw->bss) {
+ if (fw->bss_len) {
int j;
for (j = 0; j < (fw->bss_len/4); j++, offset += 4) {
- REG_WR_IND(bp, offset, fw->bss[j]);
+ REG_WR_IND(bp, offset, 0);
}
}
@@ -2894,19 +2889,16 @@ bnx2_init_cpus(struct bnx2 *bp)
if (!text)
return -ENOMEM;
rc = zlib_inflate_blob(text, FW_BUF_SIZE, bnx2_rv2p_proc1, sizeof(bnx2_rv2p_proc1));
- if (rc < 0) {
- vfree(text);
+ if (rc < 0)
goto init_cpu_err;
- }
+
load_rv2p_fw(bp, text, rc /* == len */, RV2P_PROC1);
rc = zlib_inflate_blob(text, FW_BUF_SIZE, bnx2_rv2p_proc2, sizeof(bnx2_rv2p_proc2));
- if (rc < 0) {
- vfree(text);
+ if (rc < 0)
goto init_cpu_err;
- }
+
load_rv2p_fw(bp, text, rc /* == len */, RV2P_PROC2);
- vfree(text);
/* Initialize the RX Processor. */
cpu_reg.mode = BNX2_RXP_CPU_MODE;
@@ -2927,6 +2919,7 @@ bnx2_init_cpus(struct bnx2 *bp)
else
fw = &bnx2_rxp_fw_06;
+ fw->text = text;
rc = load_cpu_fw(bp, &cpu_reg, fw);
if (rc)
goto init_cpu_err;
@@ -2950,6 +2943,7 @@ bnx2_init_cpus(struct bnx2 *bp)
else
fw = &bnx2_txp_fw_06;
+ fw->text = text;
rc = load_cpu_fw(bp, &cpu_reg, fw);
if (rc)
goto init_cpu_err;
@@ -2973,6 +2967,7 @@ bnx2_init_cpus(struct bnx2 *bp)
else
fw = &bnx2_tpat_fw_06;
+ fw->text = text;
rc = load_cpu_fw(bp, &cpu_reg, fw);
if (rc)
goto init_cpu_err;
@@ -2996,6 +2991,7 @@ bnx2_init_cpus(struct bnx2 *bp)
else
fw = &bnx2_com_fw_06;
+ fw->text = text;
rc = load_cpu_fw(bp, &cpu_reg, fw);
if (rc)
goto init_cpu_err;
@@ -3017,11 +3013,13 @@ bnx2_init_cpus(struct bnx2 *bp)
if (CHIP_NUM(bp) == CHIP_NUM_5709) {
fw = &bnx2_cp_fw_09;
+ fw->text = text;
rc = load_cpu_fw(bp, &cpu_reg, fw);
if (rc)
goto init_cpu_err;
}
init_cpu_err:
+ vfree(text);
return rc;
}
diff --git a/drivers/net/bnx2.h b/drivers/net/bnx2.h
index a717459..56c190f 100644
--- a/drivers/net/bnx2.h
+++ b/drivers/net/bnx2.h
@@ -6738,7 +6738,7 @@ struct fw_info {
const u32 text_addr;
const u32 text_len;
const u32 text_index;
-/* u32 *text;*/
+ u32 *text;
u8 *gz_text;
const u32 gz_text_len;
@@ -6752,13 +6752,11 @@ struct fw_info {
const u32 sbss_addr;
const u32 sbss_len;
const u32 sbss_index;
- const u32 *sbss;
/* BSS section. */
const u32 bss_addr;
const u32 bss_len;
const u32 bss_index;
- const u32 *bss;
/* Read-only section. */
const u32 rodata_addr;
diff --git a/drivers/net/bnx2_fw.h b/drivers/net/bnx2_fw.h
index 30f2f40..a6d7824 100644
--- a/drivers/net/bnx2_fw.h
+++ b/drivers/net/bnx2_fw.h
@@ -1048,8 +1048,6 @@ static const u32 bnx2_COM_b06FwRodata[(0x88/4) + 1] = {
0x08002bd8, 0x08002c08, 0x08002c38, 0x00000000, 0x080060cc, 0x080060cc,
0x080060cc, 0x080060cc, 0x080060cc, 0x08006100, 0x08006100, 0x08006140,
0x0800614c, 0x0800614c, 0x080060cc, 0x00000000, 0x00000000 };
-static const u32 bnx2_COM_b06FwBss[(0x88/4) + 1] = { 0x0 };
-static const u32 bnx2_COM_b06FwSbss[(0x60/4) + 1] = { 0x0 };
static struct fw_info bnx2_com_fw_06 = {
.ver_major = 0x3,
@@ -1072,12 +1070,10 @@ static struct fw_info bnx2_com_fw_06 = {
.sbss_addr = 0x08007e00,
.sbss_len = 0x60,
.sbss_index = 0x0,
- .sbss = bnx2_COM_b06FwSbss,
.bss_addr = 0x08007e60,
.bss_len = 0x88,
.bss_index = 0x0,
- .bss = bnx2_COM_b06FwBss,
.rodata_addr = 0x08007d58,
.rodata_len = 0x88,
@@ -1762,9 +1758,6 @@ static u32 bnx2_RXP_b06FwRodata[(0x278/4) + 1] = {
0x08006030, 0x08006030, 0x08006018, 0x08006030, 0x08006030, 0x08006030,
0x08006024, 0x00000000, 0x00000000 };
-static u32 bnx2_RXP_b06FwBss[(0x13dc/4) + 1] = { 0x0 };
-static u32 bnx2_RXP_b06FwSbss[(0x2c/4) + 1] = { 0x0 };
-
static struct fw_info bnx2_rxp_fw_06 = {
.ver_major = 0x2,
.ver_minor = 0x8,
@@ -1786,12 +1779,10 @@ static struct fw_info bnx2_rxp_fw_06 = {
.sbss_addr = 0x080069c0,
.sbss_len = 0x2c,
.sbss_index = 0x0,
- .sbss = bnx2_RXP_b06FwSbss,
.bss_addr = 0x080069f0,
.bss_len = 0x13dc,
.bss_index = 0x0,
- .bss = bnx2_RXP_b06FwBss,
.rodata_addr = 0x08006728,
.rodata_len = 0x278,
@@ -2257,8 +2248,6 @@ static u8 bnx2_TPAT_b06FwText[] = {
static u32 bnx2_TPAT_b06FwData[(0x0/4) + 1] = { 0x0 };
static u32 bnx2_TPAT_b06FwRodata[(0x0/4) + 1] = { 0x0 };
-static u32 bnx2_TPAT_b06FwBss[(0x250/4) + 1] = { 0x0 };
-static u32 bnx2_TPAT_b06FwSbss[(0x34/4) + 1] = { 0x0 };
static struct fw_info bnx2_tpat_fw_06 = {
.ver_major = 0x1,
@@ -2281,12 +2270,10 @@ static struct fw_info bnx2_tpat_fw_06 = {
.sbss_addr = 0x08001a60,
.sbss_len = 0x34,
.sbss_index = 0x0,
- .sbss = bnx2_TPAT_b06FwSbss,
.bss_addr = 0x08001aa0,
.bss_len = 0x250,
.bss_index = 0x0,
- .bss = bnx2_TPAT_b06FwBss,
.rodata_addr = 0x00000000,
.rodata_len = 0x0,
@@ -2714,8 +2701,6 @@ static u8 bnx2_TXP_b06FwText[] = {
static u32 bnx2_TXP_b06FwData[(0x0/4) + 1] = { 0x0 };
static u32 bnx2_TXP_b06FwRodata[(0x0/4) + 1] = { 0x0 };
-static u32 bnx2_TXP_b06FwBss[(0x1c4/4) + 1] = { 0x0 };
-static u32 bnx2_TXP_b06FwSbss[(0x38/4) + 1] = { 0x0 };
static struct fw_info bnx2_txp_fw_06 = {
.ver_major = 0x1,
@@ -2738,12 +2723,10 @@ static struct fw_info bnx2_txp_fw_06 = {
.sbss_addr = 0x08005760,
.sbss_len = 0x38,
.sbss_index = 0x0,
- .sbss = bnx2_TXP_b06FwSbss,
.bss_addr = 0x080057a0,
.bss_len = 0x1c4,
.bss_index = 0x0,
- .bss = bnx2_TXP_b06FwBss,
.rodata_addr = 0x00000000,
.rodata_len = 0x0,
diff --git a/drivers/net/bnx2_fw2.h b/drivers/net/bnx2_fw2.h
index 74f985d..5bd52be 100644
--- a/drivers/net/bnx2_fw2.h
+++ b/drivers/net/bnx2_fw2.h
@@ -1046,8 +1046,6 @@ static const u32 bnx2_COM_b09FwRodata[(0x88/4) + 1] = {
0x08002b3c, 0x08002b6c, 0x08002b9c, 0x00000000, 0x0800604c, 0x0800604c,
0x0800604c, 0x0800604c, 0x0800604c, 0x08006078, 0x08006078, 0x080060b8,
0x080060c4, 0x080060c4, 0x0800604c, 0x00000000, 0x00000000 };
-static const u32 bnx2_COM_b09FwBss[(0x88/4) + 1] = { 0x0 };
-static const u32 bnx2_COM_b09FwSbss[(0x60/4) + 1] = { 0x0 };
static struct fw_info bnx2_com_fw_09 = {
.ver_major = 0x3,
@@ -1070,12 +1068,10 @@ static struct fw_info bnx2_com_fw_09 = {
.sbss_addr = 0x08007e60,
.sbss_len = 0x60,
.sbss_index = 0x0,
- .sbss = bnx2_COM_b09FwSbss,
.bss_addr = 0x08007ec0,
.bss_len = 0x88,
.bss_index = 0x0,
- .bss = bnx2_COM_b09FwBss,
.rodata_addr = 0x08007dc0,
.rodata_len = 0x88,
@@ -2243,8 +2239,6 @@ static const u32 bnx2_CP_b09FwRodata[(0x118/4) + 1] = {
0x080032e8, 0x08003300, 0x08003320, 0x08003358, 0x08003338, 0x08003338,
0x080050d4, 0x080050d4, 0x080050d4, 0x080050d4, 0x080050d4, 0x080050fc,
0x080050fc, 0x08005124, 0x08005174, 0x08005144, 0x00000000 };
-static const u32 bnx2_CP_b09FwBss[(0x3b0/4) + 1] = { 0x0 };
-static const u32 bnx2_CP_b09FwSbss[(0xa1/4) + 1] = { 0x0 };
static struct fw_info bnx2_cp_fw_09 = {
.ver_major = 0x3,
@@ -2267,12 +2261,10 @@ static struct fw_info bnx2_cp_fw_09 = {
.sbss_addr = 0x08007024,
.sbss_len = 0xa1,
.sbss_index = 0x0,
- .sbss = bnx2_CP_b09FwSbss,
.bss_addr = 0x080070d0,
.bss_len = 0x3b0,
.bss_index = 0x0,
- .bss = bnx2_CP_b09FwBss,
.rodata_addr = 0x08006ee8,
.rodata_len = 0x118,
@@ -2953,8 +2945,6 @@ static const u32 bnx2_RXP_b09FwRodata[(0x278/4) + 1] = {
0x08006058, 0x08006070, 0x08006070, 0x08006070, 0x08006058, 0x08006070,
0x08006070, 0x08006070, 0x08006058, 0x08006070, 0x08006070, 0x08006070,
0x08006064, 0x00000000, 0x00000000 };
-static const u32 bnx2_RXP_b09FwBss[(0x13dc/4) + 1] = { 0x0 };
-static const u32 bnx2_RXP_b09FwSbss[(0x20/4) + 1] = { 0x0 };
static struct fw_info bnx2_rxp_fw_09 = {
.ver_major = 0x3,
@@ -2977,12 +2967,10 @@ static struct fw_info bnx2_rxp_fw_09 = {
.sbss_addr = 0x08006a00,
.sbss_len = 0x20,
.sbss_index = 0x0,
- .sbss = bnx2_RXP_b09FwSbss,
.bss_addr = 0x08006a20,
.bss_len = 0x13dc,
.bss_index = 0x0,
- .bss = bnx2_RXP_b09FwBss,
.rodata_addr = 0x08006768,
.rodata_len = 0x278,
@@ -3245,8 +3233,6 @@ static u8 bnx2_TPAT_b09FwText[] = {
static const u32 bnx2_TPAT_b09FwData[(0x0/4) + 1] = { 0x0 };
static const u32 bnx2_TPAT_b09FwRodata[(0x0/4) + 1] = { 0x0 };
-static const u32 bnx2_TPAT_b09FwBss[(0x850/4) + 1] = { 0x0 };
-static const u32 bnx2_TPAT_b09FwSbss[(0x2c/4) + 1] = { 0x0 };
static struct fw_info bnx2_tpat_fw_09 = {
.ver_major = 0x3,
@@ -3269,12 +3255,10 @@ static struct fw_info bnx2_tpat_fw_09 = {
.sbss_addr = 0x08002088,
.sbss_len = 0x2c,
.sbss_index = 0x0,
- .sbss = bnx2_TPAT_b09FwSbss,
.bss_addr = 0x080020c0,
.bss_len = 0x850,
.bss_index = 0x0,
- .bss = bnx2_TPAT_b09FwBss,
.rodata_addr = 0x00000000,
.rodata_len = 0x0,
@@ -4060,8 +4044,6 @@ static const u32 bnx2_TXP_b09FwRodata[(0x30/4) + 1] = {
0x08004060, 0x0800408c, 0x080040d4, 0x080040d4, 0x08003f60, 0x08003f8c,
0x08003f8c, 0x080040d4, 0x080040d4, 0x080040d4, 0x08003ff4, 0x00000000,
0x00000000 };
-static const u32 bnx2_TXP_b09FwBss[(0xa20/4) + 1] = { 0x0 };
-static const u32 bnx2_TXP_b09FwSbss[(0x8c/4) + 1] = { 0x0 };
static struct fw_info bnx2_txp_fw_09 = {
.ver_major = 0x3,
@@ -4084,12 +4066,10 @@ static struct fw_info bnx2_txp_fw_09 = {
.sbss_addr = 0x08004750,
.sbss_len = 0x8c,
.sbss_index = 0x0,
- .sbss = bnx2_TXP_b09FwSbss,
.bss_addr = 0x080047e0,
.bss_len = 0xa20,
.bss_index = 0x0,
- .bss = bnx2_TXP_b09FwBss,
.rodata_addr = 0x08004638,
.rodata_len = 0x30,
^ permalink raw reply related
* [PATCH 2.6.24 1/3][BNX2]: Add missing napi_disable() in bnx2_close().
From: Michael Chan @ 2007-10-03 0:23 UTC (permalink / raw)
To: davem; +Cc: netdev
[BNX2]: Add missing napi_disable() in bnx2_close().
bnx2_close() -> bnx2_netif_stop() will not call napi_disable() because
the netif_state is not running in bnx2_close(). To avoid confusion,
we change it to disable interrupt and napi directly in bnx2_close().
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index cd5f1b7..4887c31 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -5212,8 +5212,8 @@ bnx2_close(struct net_device *dev)
while (bp->in_reset_task)
msleep(1);
- /* This does napi_disable() for us. */
- bnx2_netif_stop(bp);
+ bnx2_disable_int_sync(bp);
+ napi_disable(&bp->napi);
del_timer_sync(&bp->timer);
if (bp->flags & NO_WOL_FLAG)
reset_code = BNX2_DRV_MSG_CODE_UNLOAD_LNK_DN;
^ permalink raw reply related
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