* [PATCH] net: fix lockdep issue in __neigh_event_send
From: Maciej Żenczykowski @ 2011-09-19 19:12 UTC (permalink / raw)
To: Maciej Żenczykowski, David S. Miller
Cc: netdev, Maciej Żenczykowski, MuraliRaja Muniraju
From: Maciej Żenczykowski <maze@google.com>
skb's should be freed once neigh->lock is no longer held.
Google-Bug-Id: 4561441
Signed-off-by: Maciej Żenczykowski <maze@google.com>
CC: MuraliRaja Muniraju <muralira@google.com>
---
net/core/neighbour.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 4002261..53d034a 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -949,6 +949,7 @@ int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
{
int rc;
bool immediate_probe = false;
+ struct sk_buff *buff_to_free = NULL;
write_lock_bh(&neigh->lock);
@@ -969,10 +970,10 @@ int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
} else {
neigh->nud_state = NUD_FAILED;
neigh->updated = jiffies;
- write_unlock_bh(&neigh->lock);
- kfree_skb(skb);
- return 1;
+ buff_to_free = skb;
+ rc = 1;
+ goto out_unlock_bh;
}
} else if (neigh->nud_state & NUD_STALE) {
NEIGH_PRINTK2("neigh %p is delayed.\n", neigh);
@@ -986,9 +987,7 @@ int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
if (skb) {
if (skb_queue_len(&neigh->arp_queue) >=
neigh->parms->queue_len) {
- struct sk_buff *buff;
- buff = __skb_dequeue(&neigh->arp_queue);
- kfree_skb(buff);
+ buff_to_free = __skb_dequeue(&neigh->arp_queue);
NEIGH_CACHE_STAT_INC(neigh->tbl, unres_discards);
}
skb_dst_force(skb);
@@ -1002,6 +1001,7 @@ out_unlock_bh:
else
write_unlock(&neigh->lock);
local_bh_enable();
+ kfree_skb(buff_to_free);
return rc;
}
EXPORT_SYMBOL(__neigh_event_send);
--
1.7.3.1
^ permalink raw reply related
* Re: [PATCH] net: fix lockdep issue in __neigh_event_send
From: Eric Dumazet @ 2011-09-19 19:42 UTC (permalink / raw)
To: Maciej Żenczykowski
Cc: Maciej Żenczykowski, David S. Miller, netdev,
MuraliRaja Muniraju
In-Reply-To: <1316459578-23413-1-git-send-email-zenczykowski@gmail.com>
Le lundi 19 septembre 2011 à 12:12 -0700, Maciej Żenczykowski a écrit :
> From: Maciej Żenczykowski <maze@google.com>
>
> skb's should be freed once neigh->lock is no longer held.
>
> Google-Bug-Id: 4561441
> Signed-off-by: Maciej Żenczykowski <maze@google.com>
> CC: MuraliRaja Muniraju <muralira@google.com>
> ---
> net/core/neighbour.c net/core/neighbour.c | 12 ++++++------
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/net/core/neighbour.c b/net/core/neighbour.c
> index 4002261..53d034a 100644
> --- a/net/core/neighbour.c
> +++ b/net/core/neighbour.c
> @@ -949,6 +949,7 @@ int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
> {
> int rc;
> bool immediate_probe = false;
> + struct sk_buff *buff_to_free = NULL;
>
> write_lock_bh(&neigh->lock);
>
> @@ -969,10 +970,10 @@ int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
> } else {
> neigh->nud_state = NUD_FAILED;
> neigh->updated = jiffies;
> - write_unlock_bh(&neigh->lock);
>
> - kfree_skb(skb);
I dont understand, here we call kfree_skb() while no lock is held.
> - return 1;
> + buff_to_free = skb;
> + rc = 1;
> + goto out_unlock_bh;
> }
> } else if (neigh->nud_state & NUD_STALE) {
> NEIGH_PRINTK2("neigh %p is delayed.\n", neigh);
> @@ -986,9 +987,7 @@ int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
> if (skb) {
> if (skb_queue_len(&neigh->arp_queue) >=
> neigh->parms->queue_len) {
> - struct sk_buff *buff;
> - buff = __skb_dequeue(&neigh->arp_queue);
> - kfree_skb(buff);
> + buff_to_free = __skb_dequeue(&neigh->arp_queue);
> NEIGH_CACHE_STAT_INC(neigh->tbl, unres_discards);
> }
> skb_dst_force(skb);
> @@ -1002,6 +1001,7 @@ out_unlock_bh:
> else
> write_unlock(&neigh->lock);
> local_bh_enable();
> + kfree_skb(buff_to_free);
> return rc;
> }
> EXPORT_SYMBOL(__neigh_event_send);
Could you give us the lockdep report please ?
Thanks !
^ permalink raw reply
* Final Notice.
From: NOTICE @ 2011-09-19 20:07 UTC (permalink / raw)
Your e-Mail id have won 1,000,000 pounds in the microsoft promo, kindly fill the below details for claims
Names.
Address.
Sex.
Age.
Tel.
Occupation.
+44 7010 039 925
Thank you for your full corporation.
Andrew Scott.
^ permalink raw reply
* Re: [PATCH] net: fix lockdep issue in __neigh_event_send
From: Maciej Żenczykowski @ 2011-09-19 20:39 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, netdev, MuraliRaja Muniraju
In-Reply-To: <1316461375.2455.4.camel@edumazet-laptop>
The first hunk was for consistency - to always free in exit path. The
second hunk is where the lockdep bug is.
LOCKDEP gives the following (it's pretty rare):
[ 90.543085] =======================================================
[ 90.544012] [ INFO: possible circular locking dependency detected ]
[ 90.544012] 2.6.34-smp-DEV #70
[ 90.544012] -------------------------------------------------------
[ 90.544012] swapper/0 is trying to acquire lock:
[ 90.544012] (&tbl->lock){++--..}, at: [<ffffffff813c106d>]
neigh_lookup+0x42/0xbf
[ 90.544012]
[ 90.544012] but task is already holding lock:
[ 90.544012] (&(&rt_hash_locks[i])->rlock){+.-...}, at:
[<ffffffff813db663>] rt_intern_hash+0xf2/0x3ad
[ 90.544012]
[ 90.544012] which lock already depends on the new lock.
[ 90.544012]
[ 90.544012]
[ 90.544012] the existing dependency chain (in reverse order) is:
[ 90.544012]
[ 90.544012] -> #2 (&(&rt_hash_locks[i])->rlock){+.-...}:
[ 90.544012] [<ffffffff810a4910>] __lock_acquire+0xb3b/0xcda
[ 90.544012] [<ffffffff810a4b72>] lock_acquire+0xc3/0xe9
[ 90.544012] [<ffffffff81430d66>] _raw_spin_lock_bh+0x36/0x45
[ 90.544012] [<ffffffff813d9659>] rt_dst_release+0x4a/0x8d
[ 90.544012] [<ffffffff813bee34>] dst_release+0x5d/0x66
[ 90.544012] [<ffffffff813af24e>] skb_release_head_state+0x1f/0xa5
[ 90.544012] [<ffffffff813aefec>] __kfree_skb+0x16/0x87
[ 90.544012] [<ffffffff813af101>] kfree_skb+0x72/0x7a
[ 90.544012] [<ffffffff813c06f9>] __neigh_event_send+0x126/0x176
[ 90.544012] [<ffffffff813c2c1b>] neigh_resolve_output+0x7f/0x267
[ 90.544012] [<ffffffff813e3057>] ip_finish_output2+0x1f2/0x221
[ 90.544012] [<ffffffff813e30ea>] ip_finish_output+0x64/0x66
[ 90.544012] [<ffffffff813e3200>] NF_HOOK_COND.clone.1+0x41/0x45
[ 90.544012] [<ffffffff813e3277>] ip_output+0x73/0x75
[ 90.544012] [<ffffffff813e1524>] dst_output+0x10/0x12
[ 90.544012] [<ffffffff813e349f>] ip_local_out+0x23/0x27
[ 90.544012] [<ffffffff813e378a>] ip_push_pending_frames+0x2e7/0x348
[ 90.544012] [<ffffffff81401a13>] udp_push_pending_frames+0x2dc/0x35c
[ 90.544012] [<ffffffff8140314e>] udp_sendmsg+0x628/0x763
[ 90.544012] [<ffffffff81409933>] inet_sendmsg+0x58/0x61
[ 90.544012] [<ffffffff813a726f>] __sock_sendmsg+0x5e/0x69
[ 90.544012] [<ffffffff813a7737>] sock_sendmsg+0xa8/0xc1
[ 90.544012] [<ffffffff813a79d9>] sys_sendmsg+0x1da/0x241
[ 90.544012] [<ffffffff813cb482>] compat_sys_sendmsg+0x14/0x16
[ 90.544012] [<ffffffff813cc081>] compat_sys_socketcall+0x13b/0x16c
[ 90.544012] [<ffffffff81059687>] sysenter_dispatch+0x7/0x2c
[ 90.544012]
[ 90.544012] -> #1 (&n->lock){++--..}:
[ 90.544012] [<ffffffff810a4910>] __lock_acquire+0xb3b/0xcda
[ 90.544012] [<ffffffff810a4b72>] lock_acquire+0xc3/0xe9
[ 90.544012] [<ffffffff81430e81>] _raw_write_lock+0x31/0x40
[ 90.544012] [<ffffffff813c16fb>] neigh_periodic_work+0xae/0x196
[ 90.544012] [<ffffffff8108a8ca>] worker_thread+0x1fb/0x2f1
[ 90.544012] [<ffffffff8108e099>] kthread+0x7f/0x87
[ 90.544012] [<ffffffff81032a94>] kernel_thread_helper+0x4/0x10
[ 90.544012]
[ 90.544012] -> #0 (&tbl->lock){++--..}:
[ 90.544012] [<ffffffff810a47ba>] __lock_acquire+0x9e5/0xcda
[ 90.544012] [<ffffffff810a4b72>] lock_acquire+0xc3/0xe9
[ 90.544012] [<ffffffff81430ffa>] _raw_read_lock_bh+0x39/0x48
[ 90.544012] [<ffffffff813c106d>] neigh_lookup+0x42/0xbf
[ 90.544012] [<ffffffff81405067>]
__neigh_lookup_errno.clone.0+0x24/0x40
[ 90.544012] [<ffffffff814054b2>] arp_bind_neighbour+0x4c/0x65
[ 90.544012] [<ffffffff813db815>] rt_intern_hash+0x2a4/0x3ad
[ 90.544012] [<ffffffff813dc054>] ip_route_output_slow+0x6ec/0x739
[ 90.544012] [<ffffffff813dc574>] __ip_route_output_key+0x1bd/0x1c9
[ 90.544012] [<ffffffff81406f45>] icmp_send+0x2bf/0x3ca
[ 90.544012] [<ffffffff813d9739>] ipv4_link_failure+0x22/0x5c
[ 90.544012] [<ffffffff81404acd>] arp_error_report+0x31/0x3d
[ 90.544012] [<ffffffff813c1172>] neigh_invalidate+0x88/0xa3
[ 90.544012] [<ffffffff813c2a1b>] neigh_timer_handler+0x1a8/0x27f
[ 90.544012] [<ffffffff8108087a>] run_timer_softirq+0x219/0x2e3
[ 90.544012] [<ffffffff8107910e>] __do_softirq+0xf7/0x1cb
[ 90.544012] [<ffffffff81032b8c>] call_softirq+0x1c/0x3e
[ 90.544012] [<ffffffff81034615>] do_softirq+0x3d/0x85
[ 90.544012] [<ffffffff81078d49>] irq_exit+0x4a/0x8c
[ 90.544012] [<ffffffff8143708c>] smp_apic_timer_interrupt+0x99/0xa7
[ 90.544012] [<ffffffff81032653>] apic_timer_interrupt+0x13/0x20
[ 90.544012] [<ffffffff81030d92>] cpu_idle+0x5c/0x79
[ 90.544012] [<ffffffff8142213f>] rest_init+0xc3/0xca
[ 90.544012] [<ffffffff81b47d77>] start_kernel+0x3e2/0x3ed
[ 90.544012] [<ffffffff81b4729f>] x86_64_start_reservations+0xaf/0xb3
[ 90.544012] [<ffffffff81b47393>] x86_64_start_kernel+0xf0/0xf7
[ 90.544012]
[ 90.544012] other info that might help us debug this:
[ 90.544012]
[ 90.544012] 3 locks held by swapper/0:
[ 90.544012] #0: (&n->timer){+.-...}, at: [<ffffffff810807e8>]
run_timer_softirq+0x187/0x2e3
[ 90.544012] #1: (slock-AF_INET){+.-...}, at: [<ffffffff814063d3>]
icmp_xmit_lock+0x35/0x47
[ 90.544012] #2: (&(&rt_hash_locks[i])->rlock){+.-...}, at:
[<ffffffff813db663>] rt_intern_hash+0xf2/0x3ad
[ 90.544012]
[ 90.544012] stack backtrace:
[ 90.544012] Pid: 0, comm: swapper Not tainted 2.6.34-smp-DEV #70
[ 90.544012] Call Trace:
[ 90.544012] <IRQ> [<ffffffff810a39c0>] print_circular_bug+0xa8/0xb7
[ 90.544012] [<ffffffff810a47ba>] __lock_acquire+0x9e5/0xcda
[ 90.544012] [<ffffffff813c106d>] ? neigh_lookup+0x42/0xbf
[ 90.544012] [<ffffffff810a4b72>] lock_acquire+0xc3/0xe9
[ 90.544012] [<ffffffff813c106d>] ? neigh_lookup+0x42/0xbf
[ 90.544012] [<ffffffff81430ffa>] _raw_read_lock_bh+0x39/0x48
[ 90.544012] [<ffffffff813c106d>] ? neigh_lookup+0x42/0xbf
[ 90.544012] [<ffffffff813c106d>] neigh_lookup+0x42/0xbf
[ 90.544012] [<ffffffff81405067>] __neigh_lookup_errno.clone.0+0x24/0x40
[ 90.544012] [<ffffffff814054b2>] arp_bind_neighbour+0x4c/0x65
[ 90.544012] [<ffffffff813db663>] ? rt_intern_hash+0xf2/0x3ad
[ 90.544012] [<ffffffff813db815>] rt_intern_hash+0x2a4/0x3ad
[ 90.544012] [<ffffffff813dc054>] ip_route_output_slow+0x6ec/0x739
[ 90.544012] [<ffffffff81078f49>] ? _local_bh_enable_ip+0xc1/0xc7
[ 90.544012] [<ffffffff813dc574>] __ip_route_output_key+0x1bd/0x1c9
[ 90.544012] [<ffffffff81406f45>] icmp_send+0x2bf/0x3ca
[ 90.544012] [<ffffffff813c2800>] ? neigh_event_ns+0x2f/0xa2
[ 90.544012] [<ffffffff813d9739>] ipv4_link_failure+0x22/0x5c
[ 90.544012] [<ffffffff81404acd>] arp_error_report+0x31/0x3d
[ 90.544012] [<ffffffff813c1172>] neigh_invalidate+0x88/0xa3
[ 90.544012] [<ffffffff813c2a1b>] neigh_timer_handler+0x1a8/0x27f
[ 90.544012] [<ffffffff8108087a>] run_timer_softirq+0x219/0x2e3
[ 90.544012] [<ffffffff810807e8>] ? run_timer_softirq+0x187/0x2e3
[ 90.544012] [<ffffffff8109158d>] ? __run_hrtimer+0xf4/0x132
[ 90.544012] [<ffffffff813c2873>] ? neigh_timer_handler+0x0/0x27f
[ 90.544012] [<ffffffff8107908d>] ? __do_softirq+0x76/0x1cb
[ 90.544012] [<ffffffff8107910e>] __do_softirq+0xf7/0x1cb
[ 90.544012] [<ffffffff8109f74a>] ? tick_program_event+0x2a/0x2c
[ 90.544012] [<ffffffff81032b8c>] call_softirq+0x1c/0x3e
[ 90.544012] [<ffffffff81034615>] do_softirq+0x3d/0x85
[ 90.544012] [<ffffffff81078d49>] irq_exit+0x4a/0x8c
[ 90.544012] [<ffffffff8143708c>] smp_apic_timer_interrupt+0x99/0xa7
[ 90.544012] [<ffffffff81032653>] apic_timer_interrupt+0x13/0x20
[ 90.544012] <EOI> [<ffffffff81039700>] ? mwait_idle+0x85/0x92
[ 90.544012] [<ffffffff810396f7>] ? mwait_idle+0x7c/0x92
[ 90.544012] [<ffffffff81030d92>] cpu_idle+0x5c/0x79
[ 90.544012] [<ffffffff8142213f>] rest_init+0xc3/0xca
[ 90.544012] [<ffffffff8142207c>] ? rest_init+0x0/0xca
[ 90.544012] [<ffffffff81b47d77>] start_kernel+0x3e2/0x3ed
[ 90.544012] [<ffffffff81b4729f>] x86_64_start_reservations+0xaf/0xb3
[ 90.544012] [<ffffffff81b47393>] x86_64_start_kernel+0xf0/0xf7
At some point in the past of the lifetime of this kernel we grabbed
exactly the following 3 locks in the following order (where the first
2 were still held while we grabbed the 3rd):
(&tbl->lock){++--..} => (&n->lock){++--..} =>
(&(&rt_hash_locks[i])->rlock){+.-...}
Now, we have grabbed the first three (are still holding them and are
trying to grab the fourth) of these locks in this order:
(&n->timer){+.-...} => (slock-AF_INET){+.-...} =>
(&(&rt_hash_locks[i])->rlock){+.-...} => (&tbl->lock){++--..}
We're complaining that this 4th lock is being grabbed after the 3rd,
when previously it was the 1st before the 3rd - we've apparently
reversed lock ordering...
^ permalink raw reply
* pull request: wireless-next 2011-09-19
From: John W. Linville @ 2011-09-19 20:36 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
David,
Here is another big batch of updates intended for 3.2 -- still
clearing-out the backlog...
This round includes lots of updates to ath9k, b43, iwlagn, and rt2x00.
Some cleanups go to mac80211, along with a number of mesh-mode fixes
from Javier.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 765cf9976e937f1cfe9159bf4534967c8bf8eb6d:
tcp: md5: remove one indirection level in tcp_md5sig_pool (2011-09-17 01:15:46 -0400)
are available in the git repository at:
ssh://infradead/~/public_git/wireless-next.git for-davem
Andres Salomon (1):
libertas: prioritize usb8388_olpc.bin firmware on OLPC machines
Arik Nemtsov (3):
wl12xx: allow 11a AP-mode for wl127x devices
mac80211: add flag to indicate HW only Tx-agg setup support
mac80211: add ssid config to bss information in AP-mode
Bill Jordan (1):
ath9k: ath9k_hw_set_txpowerlimit sets previous txpower
Christian Lamparter (1):
minstrel_ht: fix Open BA session request floods
Dan Carpenter (3):
mac80211: handle allocation failures in mesh_pathtbl_init()
iwlwifi: fix double assign in iwl_start_tx_ba_trans_ready()
iwlwifi: signedness bug in iwl_trans_pcie_tx_agg_alloc()
Eliad Peller (5):
wl12xx: initialize rate_set on band rates initialization
wl12xx: increase psm_entry_retries
wl12xx: enter psm only after station role was started
nl80211/cfg80211: add WIPHY_FLAG_AP_UAPSD flag
nl80211/cfg80211/mac80211: fix wme docs
Emmanuel Grumbach (6):
iwlagn: merge iwl_pci_down and iwl_pci_remove
iwlagn: remove priv dereferences from the transport layer
iwlagn: clean up of transport layer
iwlagn: move traffic_log back to upper layer
iwlagn: iwl-trans.c can't dereference iwl_priv any more
iwlagn: fix compilation when debug flags is unset
Felix Fietkau (27):
ath9k_hw: do not apply the 2.4 ghz ack timeout workaround to cts
mac80211: retry sending failed BAR frames later instead of tearing down aggr
ath9k_hw: drop an unused column in AR5008-AR9002 initvals
ath9k_hw: fix the last register write for ar5416 addac
ath9k: fix checks for first subframe delimiter padding
mac80211: make ieee80211_send_bar available for drivers
ath9k: eliminate common->{rx,tx}_chainmask
ath9k: move a few functions around
ath9k: always call ath_reset from workqueue context
ath9k: merge reset related functions
ath9k: implement .get_antenna and .set_antenna
ath9k: fix enabling interrupts after a hardware error interrupt
ath9k: make beacon timer initialization more reliable
ath9k: ensure that rx is not enabled during a reset
ath9k: remove ATH_TX_XRETRY and BUF_XRETRY flags
ath9k: reduce the number of functions that access the tx descriptor
ath9k: move ath_buf_set_rate to remove a forward declaration
ath9k: call ath9k_hw_set_desc_link for beacon descriptors
ath9k_hw: do not recalculate the descriptor checksum in ar9003_hw_fill_txdesc
ath9k_hw: add a new API for setting tx descriptors
ath9k: use the new API for setting tx descriptors
ath9k_hw: remove the old tx descriptor API
ath9k: optimize ath9k_ps_restore
ath9k: remove a redundant check in ath_tx_form_aggr
ath9k: optimize ath_tx_rc_status usage
ath9k: do not insert padding into tx buffers on AR9380+
mac80211: fix endian issues and comments for BAR failure handling
Guy Eilam (1):
wl12xx: use 2 spare TX blocks for GEM cipher
Helmut Schaa (12):
rt2x00: Minor optimizazion in txdone path
rt2x00: Add LED_CFG register description
rt2x00: Remove incorrect led blink
rt2x00: Update some TX descriptor
rt2x00: Avoid unnecessary uncached
rt2x00: Move bssidx calculation into its own function
rt2x00: Introduce sta_add/remove callbacks
rt2x00: Add WCID to crypto struct
rt2x00: Add WCID to HT TX descriptor
rt2x00: Make use of sta_add/remove callbacks in rt2800
rt2x00: Forbid aggregation for STAs not programmed into the hw
rt2x00: Use the available helper functions to initialize the WCID table
Javier Cardona (12):
mac80211: Defer tranmission of mesh path errors
mac80211: Fix RCU pointer dereference in mesh_path_discard_frame()
mac80211: Remove mesh paths when an interface is removed
mac80211: Improve mpath state locking
mac80211: Remove redundant mesh path expiration checks
mac80211: Don't iterate twice over all mpaths when once in sufficient
mac80211: Consolidate {mesh,mpp}_path_flush into one function
mac80211: Consolidate mesh path duplicated functions
mac80211: Stop forwarding mesh traffic when tx queues are full
mac80211: Start implementing QoS support for mesh interfaces
mac80211: Mesh data frames must have the QoS header
mac80211: Mark all mesh stations as QoS capable
Joe Perches (3):
mac80211: Remove unnecessary OOM logging messages
rfkill: Remove unnecessary OOM logging messages
wireless: Remove unnecessary OOM logging messages
Johannes Berg (2):
mac80211: further optimise buffer expiry timer
cfg80211: verify format of uAPSD information
John W. Linville (2):
Merge branch 'for-linville' of git://github.com/lucacoelho/wl12xx
Merge branch 'master' of ssh://infradead/~/public_git/wireless-next into for-davem
Kalle Valo (1):
MAINTAINERS: update ath6kl
Luciano Coelho (4):
wl12xx: add support for multiple SSIDs in sched_scan
wl12xx: use SCAN_SSID_TYPE_PUBLIC when using the wildcard in sched_scan
nl80211/cfg80211: add match filtering for sched_scan
Merge branch 'wl12xx-next' into for-linville
Mohammed Shafi Shajakhan (2):
ath9k: enable LED pin for AR946/8x chipsets
ath9k: Fix PS wrappers and enabling LED
Pavel Roskin (1):
cfg80211: print bandwidth in chan_reg_rule_print_dbg()
Rafał Miłecki (20):
b43: LCN-PHY: add R/W ops for PHY and radio
b43: LCN-PHY: implement more PHY ops before radio init
b43: LCN-PHY: prepare functions for channel switching
ssb: use u16 for storing board rev
bcma: extract some basic info about board from SPROM
b43: LCN-PHY: implement saving and restoring PHY & radio configuration
b43: LCN-PHY: minor fixes
b43: LCN-PHY: put tables functions in correct file
b43: LCN-PHY: rewrite 0x7 table at the end of init
b43: LCN-PHY: upload additional 0x7 table
b43: LCN-PHY: rename functions, get rid of magic names
b43: LCN-PHY: add conditions for few operations
b43: N-PHY: implement enabling TX power control
b43: drop Copyright for not really copyrightable info
b43: add my copyrights and myself as the module author
b43: LCN-PHY: load TX gain table on init
b43: N-PHY: use helper for checking IPA
b43: N-PHY: replace some hacks with nice tables ops
b43: N-PHY: split workarounds into per-PHY-ver functions
b43: N-PHY: implement few random missing ops
Rajkumar Manoharan (6):
ath9k_hw: Fix rx latency of 11a mode
mac80211: stop tx before doing hw config and rate update
ath9k: Take the samples in unassociated state
ath9k: Move cycle conters under cc_lock
ath9k_hw: Fix magnitude/phase average in TxIQ Calibration
ath9k_hw: Do full chip reset on 11A channels for AR9003
Randy Dunlap (1):
wireless: fix kernel-doc warning in net/cfg80211.h
Senthil Balasubramanian (4):
ath9k_hw: Add initvals and register definitions for AR946/8x chipsets.
ath9k_hw: Split tx/rx gain table initval handling
ath9k_hw: Add support for AR946/8x chipsets.
ath9k_hw: move register definitions to header files
Shahar Levi (1):
mac80211: Update device channel in case of HW channel switch supported
Sven Neumann (2):
cfg80211: hold reg_mutex when updating regulatory
cfg80211: reorder code to obsolete forward declaration
Thomas Pedersen (1):
mac80211: check if mesh frame is in RMC after decrypt
Vivek Natarajan (1):
cfg80211/nl80211: Indicate roaming feature capability to userspace.
Wey-Yi Guy (4):
iwlagn: only perform necessary calibration at init time
iwlagn: disply queue read/write pointer when stuck
iwlagn: enable 11n support for "_d" sku
iwlagn: remove lines from the wrong place
Yogesh Ashok Powar (2):
mwl8k: Set hardware flag IEEE80211_HW_AP_LINK_PS
mwifiex: replace kmalloc & memcpy sequence with kmemdup
zero.lin (1):
rt2x00: Add new chipset support
MAINTAINERS | 14 +-
drivers/bcma/sprom.c | 9 +
drivers/net/wireless/ath/ath.h | 3 -
drivers/net/wireless/ath/ath9k/ar5008_initvals.h | 131 +-
drivers/net/wireless/ath/ath9k/ar9001_initvals.h | 266 +-
drivers/net/wireless/ath/ath9k/ar9002_hw.c | 48 +-
drivers/net/wireless/ath/ath9k/ar9002_initvals.h | 3403 ++++++++++----------
drivers/net/wireless/ath/ath9k/ar9002_mac.c | 257 +-
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 17 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 117 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 3 +-
drivers/net/wireless/ath/ath9k/ar9003_hw.c | 581 +++-
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 331 +--
drivers/net/wireless/ath/ath9k/ar9003_paprd.c | 15 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 10 +
drivers/net/wireless/ath/ath9k/ar9003_phy.h | 100 +-
.../net/wireless/ath/ath9k/ar9480_1p0_initvals.h | 1833 +++++++++++
.../net/wireless/ath/ath9k/ar9480_2p0_initvals.h | 1928 +++++++++++
drivers/net/wireless/ath/ath9k/ath9k.h | 14 +-
drivers/net/wireless/ath/ath9k/beacon.c | 56 +-
drivers/net/wireless/ath/ath9k/debug.c | 41 +-
drivers/net/wireless/ath/ath9k/debug.h | 6 +-
drivers/net/wireless/ath/ath9k/gpio.c | 2 +
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 7 +-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 3 +-
drivers/net/wireless/ath/ath9k/hw-ops.h | 58 +-
drivers/net/wireless/ath/ath9k/hw.c | 102 +-
drivers/net/wireless/ath/ath9k/hw.h | 28 +-
drivers/net/wireless/ath/ath9k/init.c | 42 +-
drivers/net/wireless/ath/ath9k/mac.c | 12 -
drivers/net/wireless/ath/ath9k/mac.h | 42 +-
drivers/net/wireless/ath/ath9k/main.c | 535 ++--
drivers/net/wireless/ath/ath9k/pci.c | 5 +-
drivers/net/wireless/ath/ath9k/recv.c | 7 +-
drivers/net/wireless/ath/ath9k/reg.h | 62 +-
drivers/net/wireless/ath/ath9k/xmit.c | 607 ++--
drivers/net/wireless/b43/b43.h | 2 +
drivers/net/wireless/b43/bus.c | 2 +
drivers/net/wireless/b43/main.c | 3 +
drivers/net/wireless/b43/phy_ht.c | 2 +
drivers/net/wireless/b43/phy_lcn.c | 288 ++-
drivers/net/wireless/b43/phy_n.c | 543 ++--
drivers/net/wireless/b43/phy_n.h | 4 +
drivers/net/wireless/b43/radio_2055.c | 1 +
drivers/net/wireless/b43/radio_2056.c | 2 +
drivers/net/wireless/b43/radio_2056.h | 26 -
drivers/net/wireless/b43/radio_2059.c | 2 +
drivers/net/wireless/b43/tables_nphy.c | 1 +
drivers/net/wireless/b43/tables_phy_ht.c | 2 +
drivers/net/wireless/b43/tables_phy_lcn.c | 255 ++-
drivers/net/wireless/b43/tables_phy_lcn.h | 2 +
drivers/net/wireless/iwlwifi/iwl-2000.c | 1 +
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-agn-rxon.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-agn-tt.h | 1 -
drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-agn-ucode.c | 5 +-
drivers/net/wireless/iwlwifi/iwl-agn.c | 10 +-
drivers/net/wireless/iwlwifi/iwl-agn.h | 2 -
drivers/net/wireless/iwlwifi/iwl-commands.h | 7 +-
drivers/net/wireless/iwlwifi/iwl-core.c | 19 +-
drivers/net/wireless/iwlwifi/iwl-core.h | 22 -
drivers/net/wireless/iwlwifi/iwl-csr.h | 18 +
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 85 +
drivers/net/wireless/iwlwifi/iwl-dev.h | 202 +--
drivers/net/wireless/iwlwifi/iwl-helpers.h | 23 -
drivers/net/wireless/iwlwifi/iwl-pci.c | 18 +-
drivers/net/wireless/iwlwifi/iwl-rx.c | 83 +-
drivers/net/wireless/iwlwifi/iwl-shared.h | 52 +
drivers/net/wireless/iwlwifi/iwl-sta.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-sv-open.c | 1 +
drivers/net/wireless/iwlwifi/iwl-trans-int-pcie.h | 110 +-
drivers/net/wireless/iwlwifi/iwl-trans-rx-pcie.c | 45 +-
drivers/net/wireless/iwlwifi/iwl-trans-tx-pcie.c | 130 +-
drivers/net/wireless/iwlwifi/iwl-trans.c | 402 +--
drivers/net/wireless/iwlwifi/iwl-trans.h | 66 +-
drivers/net/wireless/libertas/if_usb.c | 21 +
drivers/net/wireless/mwifiex/join.c | 3 +-
drivers/net/wireless/mwifiex/scan.c | 6 +-
drivers/net/wireless/mwifiex/sta_ioctl.c | 9 +-
drivers/net/wireless/mwl8k.c | 8 +
drivers/net/wireless/rt2x00/rt2800.h | 3 +
drivers/net/wireless/rt2x00/rt2800lib.c | 191 +-
drivers/net/wireless/rt2x00/rt2800lib.h | 5 +-
drivers/net/wireless/rt2x00/rt2800pci.c | 15 +-
drivers/net/wireless/rt2x00/rt2800usb.c | 7 +-
drivers/net/wireless/rt2x00/rt2x00.h | 30 +
drivers/net/wireless/rt2x00/rt2x00dev.c | 21 +
drivers/net/wireless/rt2x00/rt2x00mac.c | 50 +-
drivers/net/wireless/rt2x00/rt2x00queue.c | 7 +-
drivers/net/wireless/rt2x00/rt2x00queue.h | 5 +-
drivers/net/wireless/wl12xx/boot.c | 4 +-
drivers/net/wireless/wl12xx/main.c | 50 +-
drivers/net/wireless/wl12xx/scan.c | 66 +-
drivers/net/wireless/wl12xx/tx.c | 8 +-
drivers/net/wireless/wl12xx/tx.h | 1 +
drivers/net/wireless/wl12xx/wl12xx.h | 3 +
include/linux/ieee80211.h | 2 +
include/linux/nl80211.h | 57 +-
include/linux/ssb/ssb.h | 2 +-
include/net/cfg80211.h | 31 +
include/net/mac80211.h | 29 +
net/mac80211/agg-rx.c | 19 +-
net/mac80211/agg-tx.c | 42 +-
net/mac80211/cfg.c | 21 +-
net/mac80211/debugfs.c | 5 +
net/mac80211/debugfs_netdev.c | 3 +
net/mac80211/ht.c | 6 +-
net/mac80211/ieee80211_i.h | 3 +-
net/mac80211/iface.c | 6 +
net/mac80211/mesh.c | 8 +-
net/mac80211/mesh.h | 6 +-
net/mac80211/mesh_hwmp.c | 31 +-
net/mac80211/mesh_pathtbl.c | 192 +-
net/mac80211/mesh_plink.c | 2 +-
net/mac80211/mlme.c | 36 +-
net/mac80211/rc80211_minstrel_ht.c | 3 +-
net/mac80211/rx.c | 35 +-
net/mac80211/spectmgmt.c | 6 +-
net/mac80211/sta_info.c | 10 +-
net/mac80211/sta_info.h | 5 +
net/mac80211/status.c | 53 +-
net/mac80211/tx.c | 26 +-
net/mac80211/util.c | 13 +-
net/mac80211/wme.c | 16 +-
net/mac80211/wme.h | 3 +-
net/mac80211/work.c | 6 +-
net/rfkill/rfkill-regulator.c | 1 -
net/wireless/core.c | 2 +-
net/wireless/core.h | 2 -
net/wireless/lib80211_crypt_ccmp.c | 2 -
net/wireless/lib80211_crypt_tkip.c | 4 -
net/wireless/lib80211_crypt_wep.c | 4 -
net/wireless/nl80211.c | 73 +-
net/wireless/reg.c | 33 +-
net/wireless/reg.h | 2 +
net/wireless/util.c | 5 +-
137 files changed, 9864 insertions(+), 4598 deletions(-)
create mode 100644 drivers/net/wireless/ath/ath9k/ar9480_1p0_initvals.h
create mode 100644 drivers/net/wireless/ath/ath9k/ar9480_2p0_initvals.h
Omnibus patch is available here:
http://bombadil.infradead.org/~linville/wireless-next-2011-09-19.patch.gz
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: pull request: wireless-next 2011-09-19
From: John W. Linville @ 2011-09-19 20:48 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110919203639.GF2608-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Oops -- fat-fingered the linux-wireless email address...
On Mon, Sep 19, 2011 at 04:36:39PM -0400, John W. Linville wrote:
> David,
>
> Here is another big batch of updates intended for 3.2 -- still
> clearing-out the backlog...
>
> This round includes lots of updates to ath9k, b43, iwlagn, and rt2x00.
> Some cleanups go to mac80211, along with a number of mesh-mode fixes
> from Javier.
>
> Please let me know if there are problems!
>
> Thanks,
>
> John
>
> ---
>
> The following changes since commit 765cf9976e937f1cfe9159bf4534967c8bf8eb6d:
>
> tcp: md5: remove one indirection level in tcp_md5sig_pool (2011-09-17 01:15:46 -0400)
>
> are available in the git repository at:
> ssh://infradead/~/public_git/wireless-next.git for-davem
>
> Andres Salomon (1):
> libertas: prioritize usb8388_olpc.bin firmware on OLPC machines
>
> Arik Nemtsov (3):
> wl12xx: allow 11a AP-mode for wl127x devices
> mac80211: add flag to indicate HW only Tx-agg setup support
> mac80211: add ssid config to bss information in AP-mode
>
> Bill Jordan (1):
> ath9k: ath9k_hw_set_txpowerlimit sets previous txpower
>
> Christian Lamparter (1):
> minstrel_ht: fix Open BA session request floods
>
> Dan Carpenter (3):
> mac80211: handle allocation failures in mesh_pathtbl_init()
> iwlwifi: fix double assign in iwl_start_tx_ba_trans_ready()
> iwlwifi: signedness bug in iwl_trans_pcie_tx_agg_alloc()
>
> Eliad Peller (5):
> wl12xx: initialize rate_set on band rates initialization
> wl12xx: increase psm_entry_retries
> wl12xx: enter psm only after station role was started
> nl80211/cfg80211: add WIPHY_FLAG_AP_UAPSD flag
> nl80211/cfg80211/mac80211: fix wme docs
>
> Emmanuel Grumbach (6):
> iwlagn: merge iwl_pci_down and iwl_pci_remove
> iwlagn: remove priv dereferences from the transport layer
> iwlagn: clean up of transport layer
> iwlagn: move traffic_log back to upper layer
> iwlagn: iwl-trans.c can't dereference iwl_priv any more
> iwlagn: fix compilation when debug flags is unset
>
> Felix Fietkau (27):
> ath9k_hw: do not apply the 2.4 ghz ack timeout workaround to cts
> mac80211: retry sending failed BAR frames later instead of tearing down aggr
> ath9k_hw: drop an unused column in AR5008-AR9002 initvals
> ath9k_hw: fix the last register write for ar5416 addac
> ath9k: fix checks for first subframe delimiter padding
> mac80211: make ieee80211_send_bar available for drivers
> ath9k: eliminate common->{rx,tx}_chainmask
> ath9k: move a few functions around
> ath9k: always call ath_reset from workqueue context
> ath9k: merge reset related functions
> ath9k: implement .get_antenna and .set_antenna
> ath9k: fix enabling interrupts after a hardware error interrupt
> ath9k: make beacon timer initialization more reliable
> ath9k: ensure that rx is not enabled during a reset
> ath9k: remove ATH_TX_XRETRY and BUF_XRETRY flags
> ath9k: reduce the number of functions that access the tx descriptor
> ath9k: move ath_buf_set_rate to remove a forward declaration
> ath9k: call ath9k_hw_set_desc_link for beacon descriptors
> ath9k_hw: do not recalculate the descriptor checksum in ar9003_hw_fill_txdesc
> ath9k_hw: add a new API for setting tx descriptors
> ath9k: use the new API for setting tx descriptors
> ath9k_hw: remove the old tx descriptor API
> ath9k: optimize ath9k_ps_restore
> ath9k: remove a redundant check in ath_tx_form_aggr
> ath9k: optimize ath_tx_rc_status usage
> ath9k: do not insert padding into tx buffers on AR9380+
> mac80211: fix endian issues and comments for BAR failure handling
>
> Guy Eilam (1):
> wl12xx: use 2 spare TX blocks for GEM cipher
>
> Helmut Schaa (12):
> rt2x00: Minor optimizazion in txdone path
> rt2x00: Add LED_CFG register description
> rt2x00: Remove incorrect led blink
> rt2x00: Update some TX descriptor
> rt2x00: Avoid unnecessary uncached
> rt2x00: Move bssidx calculation into its own function
> rt2x00: Introduce sta_add/remove callbacks
> rt2x00: Add WCID to crypto struct
> rt2x00: Add WCID to HT TX descriptor
> rt2x00: Make use of sta_add/remove callbacks in rt2800
> rt2x00: Forbid aggregation for STAs not programmed into the hw
> rt2x00: Use the available helper functions to initialize the WCID table
>
> Javier Cardona (12):
> mac80211: Defer tranmission of mesh path errors
> mac80211: Fix RCU pointer dereference in mesh_path_discard_frame()
> mac80211: Remove mesh paths when an interface is removed
> mac80211: Improve mpath state locking
> mac80211: Remove redundant mesh path expiration checks
> mac80211: Don't iterate twice over all mpaths when once in sufficient
> mac80211: Consolidate {mesh,mpp}_path_flush into one function
> mac80211: Consolidate mesh path duplicated functions
> mac80211: Stop forwarding mesh traffic when tx queues are full
> mac80211: Start implementing QoS support for mesh interfaces
> mac80211: Mesh data frames must have the QoS header
> mac80211: Mark all mesh stations as QoS capable
>
> Joe Perches (3):
> mac80211: Remove unnecessary OOM logging messages
> rfkill: Remove unnecessary OOM logging messages
> wireless: Remove unnecessary OOM logging messages
>
> Johannes Berg (2):
> mac80211: further optimise buffer expiry timer
> cfg80211: verify format of uAPSD information
>
> John W. Linville (2):
> Merge branch 'for-linville' of git://github.com/lucacoelho/wl12xx
> Merge branch 'master' of ssh://infradead/~/public_git/wireless-next into for-davem
>
> Kalle Valo (1):
> MAINTAINERS: update ath6kl
>
> Luciano Coelho (4):
> wl12xx: add support for multiple SSIDs in sched_scan
> wl12xx: use SCAN_SSID_TYPE_PUBLIC when using the wildcard in sched_scan
> nl80211/cfg80211: add match filtering for sched_scan
> Merge branch 'wl12xx-next' into for-linville
>
> Mohammed Shafi Shajakhan (2):
> ath9k: enable LED pin for AR946/8x chipsets
> ath9k: Fix PS wrappers and enabling LED
>
> Pavel Roskin (1):
> cfg80211: print bandwidth in chan_reg_rule_print_dbg()
>
> Rafał Miłecki (20):
> b43: LCN-PHY: add R/W ops for PHY and radio
> b43: LCN-PHY: implement more PHY ops before radio init
> b43: LCN-PHY: prepare functions for channel switching
> ssb: use u16 for storing board rev
> bcma: extract some basic info about board from SPROM
> b43: LCN-PHY: implement saving and restoring PHY & radio configuration
> b43: LCN-PHY: minor fixes
> b43: LCN-PHY: put tables functions in correct file
> b43: LCN-PHY: rewrite 0x7 table at the end of init
> b43: LCN-PHY: upload additional 0x7 table
> b43: LCN-PHY: rename functions, get rid of magic names
> b43: LCN-PHY: add conditions for few operations
> b43: N-PHY: implement enabling TX power control
> b43: drop Copyright for not really copyrightable info
> b43: add my copyrights and myself as the module author
> b43: LCN-PHY: load TX gain table on init
> b43: N-PHY: use helper for checking IPA
> b43: N-PHY: replace some hacks with nice tables ops
> b43: N-PHY: split workarounds into per-PHY-ver functions
> b43: N-PHY: implement few random missing ops
>
> Rajkumar Manoharan (6):
> ath9k_hw: Fix rx latency of 11a mode
> mac80211: stop tx before doing hw config and rate update
> ath9k: Take the samples in unassociated state
> ath9k: Move cycle conters under cc_lock
> ath9k_hw: Fix magnitude/phase average in TxIQ Calibration
> ath9k_hw: Do full chip reset on 11A channels for AR9003
>
> Randy Dunlap (1):
> wireless: fix kernel-doc warning in net/cfg80211.h
>
> Senthil Balasubramanian (4):
> ath9k_hw: Add initvals and register definitions for AR946/8x chipsets.
> ath9k_hw: Split tx/rx gain table initval handling
> ath9k_hw: Add support for AR946/8x chipsets.
> ath9k_hw: move register definitions to header files
>
> Shahar Levi (1):
> mac80211: Update device channel in case of HW channel switch supported
>
> Sven Neumann (2):
> cfg80211: hold reg_mutex when updating regulatory
> cfg80211: reorder code to obsolete forward declaration
>
> Thomas Pedersen (1):
> mac80211: check if mesh frame is in RMC after decrypt
>
> Vivek Natarajan (1):
> cfg80211/nl80211: Indicate roaming feature capability to userspace.
>
> Wey-Yi Guy (4):
> iwlagn: only perform necessary calibration at init time
> iwlagn: disply queue read/write pointer when stuck
> iwlagn: enable 11n support for "_d" sku
> iwlagn: remove lines from the wrong place
>
> Yogesh Ashok Powar (2):
> mwl8k: Set hardware flag IEEE80211_HW_AP_LINK_PS
> mwifiex: replace kmalloc & memcpy sequence with kmemdup
>
> zero.lin (1):
> rt2x00: Add new chipset support
>
> MAINTAINERS | 14 +-
> drivers/bcma/sprom.c | 9 +
> drivers/net/wireless/ath/ath.h | 3 -
> drivers/net/wireless/ath/ath9k/ar5008_initvals.h | 131 +-
> drivers/net/wireless/ath/ath9k/ar9001_initvals.h | 266 +-
> drivers/net/wireless/ath/ath9k/ar9002_hw.c | 48 +-
> drivers/net/wireless/ath/ath9k/ar9002_initvals.h | 3403 ++++++++++----------
> drivers/net/wireless/ath/ath9k/ar9002_mac.c | 257 +-
> drivers/net/wireless/ath/ath9k/ar9003_calib.c | 17 +-
> drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 117 +-
> drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 3 +-
> drivers/net/wireless/ath/ath9k/ar9003_hw.c | 581 +++-
> drivers/net/wireless/ath/ath9k/ar9003_mac.c | 331 +--
> drivers/net/wireless/ath/ath9k/ar9003_paprd.c | 15 +-
> drivers/net/wireless/ath/ath9k/ar9003_phy.c | 10 +
> drivers/net/wireless/ath/ath9k/ar9003_phy.h | 100 +-
> .../net/wireless/ath/ath9k/ar9480_1p0_initvals.h | 1833 +++++++++++
> .../net/wireless/ath/ath9k/ar9480_2p0_initvals.h | 1928 +++++++++++
> drivers/net/wireless/ath/ath9k/ath9k.h | 14 +-
> drivers/net/wireless/ath/ath9k/beacon.c | 56 +-
> drivers/net/wireless/ath/ath9k/debug.c | 41 +-
> drivers/net/wireless/ath/ath9k/debug.h | 6 +-
> drivers/net/wireless/ath/ath9k/gpio.c | 2 +
> drivers/net/wireless/ath/ath9k/htc_drv_init.c | 7 +-
> drivers/net/wireless/ath/ath9k/htc_drv_main.c | 3 +-
> drivers/net/wireless/ath/ath9k/hw-ops.h | 58 +-
> drivers/net/wireless/ath/ath9k/hw.c | 102 +-
> drivers/net/wireless/ath/ath9k/hw.h | 28 +-
> drivers/net/wireless/ath/ath9k/init.c | 42 +-
> drivers/net/wireless/ath/ath9k/mac.c | 12 -
> drivers/net/wireless/ath/ath9k/mac.h | 42 +-
> drivers/net/wireless/ath/ath9k/main.c | 535 ++--
> drivers/net/wireless/ath/ath9k/pci.c | 5 +-
> drivers/net/wireless/ath/ath9k/recv.c | 7 +-
> drivers/net/wireless/ath/ath9k/reg.h | 62 +-
> drivers/net/wireless/ath/ath9k/xmit.c | 607 ++--
> drivers/net/wireless/b43/b43.h | 2 +
> drivers/net/wireless/b43/bus.c | 2 +
> drivers/net/wireless/b43/main.c | 3 +
> drivers/net/wireless/b43/phy_ht.c | 2 +
> drivers/net/wireless/b43/phy_lcn.c | 288 ++-
> drivers/net/wireless/b43/phy_n.c | 543 ++--
> drivers/net/wireless/b43/phy_n.h | 4 +
> drivers/net/wireless/b43/radio_2055.c | 1 +
> drivers/net/wireless/b43/radio_2056.c | 2 +
> drivers/net/wireless/b43/radio_2056.h | 26 -
> drivers/net/wireless/b43/radio_2059.c | 2 +
> drivers/net/wireless/b43/tables_nphy.c | 1 +
> drivers/net/wireless/b43/tables_phy_ht.c | 2 +
> drivers/net/wireless/b43/tables_phy_lcn.c | 255 ++-
> drivers/net/wireless/b43/tables_phy_lcn.h | 2 +
> drivers/net/wireless/iwlwifi/iwl-2000.c | 1 +
> drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 2 +-
> drivers/net/wireless/iwlwifi/iwl-agn-rxon.c | 4 +-
> drivers/net/wireless/iwlwifi/iwl-agn-tt.h | 1 -
> drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 2 +-
> drivers/net/wireless/iwlwifi/iwl-agn-ucode.c | 5 +-
> drivers/net/wireless/iwlwifi/iwl-agn.c | 10 +-
> drivers/net/wireless/iwlwifi/iwl-agn.h | 2 -
> drivers/net/wireless/iwlwifi/iwl-commands.h | 7 +-
> drivers/net/wireless/iwlwifi/iwl-core.c | 19 +-
> drivers/net/wireless/iwlwifi/iwl-core.h | 22 -
> drivers/net/wireless/iwlwifi/iwl-csr.h | 18 +
> drivers/net/wireless/iwlwifi/iwl-debugfs.c | 85 +
> drivers/net/wireless/iwlwifi/iwl-dev.h | 202 +--
> drivers/net/wireless/iwlwifi/iwl-helpers.h | 23 -
> drivers/net/wireless/iwlwifi/iwl-pci.c | 18 +-
> drivers/net/wireless/iwlwifi/iwl-rx.c | 83 +-
> drivers/net/wireless/iwlwifi/iwl-shared.h | 52 +
> drivers/net/wireless/iwlwifi/iwl-sta.c | 4 +-
> drivers/net/wireless/iwlwifi/iwl-sv-open.c | 1 +
> drivers/net/wireless/iwlwifi/iwl-trans-int-pcie.h | 110 +-
> drivers/net/wireless/iwlwifi/iwl-trans-rx-pcie.c | 45 +-
> drivers/net/wireless/iwlwifi/iwl-trans-tx-pcie.c | 130 +-
> drivers/net/wireless/iwlwifi/iwl-trans.c | 402 +--
> drivers/net/wireless/iwlwifi/iwl-trans.h | 66 +-
> drivers/net/wireless/libertas/if_usb.c | 21 +
> drivers/net/wireless/mwifiex/join.c | 3 +-
> drivers/net/wireless/mwifiex/scan.c | 6 +-
> drivers/net/wireless/mwifiex/sta_ioctl.c | 9 +-
> drivers/net/wireless/mwl8k.c | 8 +
> drivers/net/wireless/rt2x00/rt2800.h | 3 +
> drivers/net/wireless/rt2x00/rt2800lib.c | 191 +-
> drivers/net/wireless/rt2x00/rt2800lib.h | 5 +-
> drivers/net/wireless/rt2x00/rt2800pci.c | 15 +-
> drivers/net/wireless/rt2x00/rt2800usb.c | 7 +-
> drivers/net/wireless/rt2x00/rt2x00.h | 30 +
> drivers/net/wireless/rt2x00/rt2x00dev.c | 21 +
> drivers/net/wireless/rt2x00/rt2x00mac.c | 50 +-
> drivers/net/wireless/rt2x00/rt2x00queue.c | 7 +-
> drivers/net/wireless/rt2x00/rt2x00queue.h | 5 +-
> drivers/net/wireless/wl12xx/boot.c | 4 +-
> drivers/net/wireless/wl12xx/main.c | 50 +-
> drivers/net/wireless/wl12xx/scan.c | 66 +-
> drivers/net/wireless/wl12xx/tx.c | 8 +-
> drivers/net/wireless/wl12xx/tx.h | 1 +
> drivers/net/wireless/wl12xx/wl12xx.h | 3 +
> include/linux/ieee80211.h | 2 +
> include/linux/nl80211.h | 57 +-
> include/linux/ssb/ssb.h | 2 +-
> include/net/cfg80211.h | 31 +
> include/net/mac80211.h | 29 +
> net/mac80211/agg-rx.c | 19 +-
> net/mac80211/agg-tx.c | 42 +-
> net/mac80211/cfg.c | 21 +-
> net/mac80211/debugfs.c | 5 +
> net/mac80211/debugfs_netdev.c | 3 +
> net/mac80211/ht.c | 6 +-
> net/mac80211/ieee80211_i.h | 3 +-
> net/mac80211/iface.c | 6 +
> net/mac80211/mesh.c | 8 +-
> net/mac80211/mesh.h | 6 +-
> net/mac80211/mesh_hwmp.c | 31 +-
> net/mac80211/mesh_pathtbl.c | 192 +-
> net/mac80211/mesh_plink.c | 2 +-
> net/mac80211/mlme.c | 36 +-
> net/mac80211/rc80211_minstrel_ht.c | 3 +-
> net/mac80211/rx.c | 35 +-
> net/mac80211/spectmgmt.c | 6 +-
> net/mac80211/sta_info.c | 10 +-
> net/mac80211/sta_info.h | 5 +
> net/mac80211/status.c | 53 +-
> net/mac80211/tx.c | 26 +-
> net/mac80211/util.c | 13 +-
> net/mac80211/wme.c | 16 +-
> net/mac80211/wme.h | 3 +-
> net/mac80211/work.c | 6 +-
> net/rfkill/rfkill-regulator.c | 1 -
> net/wireless/core.c | 2 +-
> net/wireless/core.h | 2 -
> net/wireless/lib80211_crypt_ccmp.c | 2 -
> net/wireless/lib80211_crypt_tkip.c | 4 -
> net/wireless/lib80211_crypt_wep.c | 4 -
> net/wireless/nl80211.c | 73 +-
> net/wireless/reg.c | 33 +-
> net/wireless/reg.h | 2 +
> net/wireless/util.c | 5 +-
> 137 files changed, 9864 insertions(+), 4598 deletions(-)
> create mode 100644 drivers/net/wireless/ath/ath9k/ar9480_1p0_initvals.h
> create mode 100644 drivers/net/wireless/ath/ath9k/ar9480_2p0_initvals.h
>
> Omnibus patch is available here:
>
> http://bombadil.infradead.org/~linville/wireless-next-2011-09-19.patch.gz
>
> --
> John W. Linville Someday the world will need a hero, and you
> linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: fix lockdep issue in __neigh_event_send
From: Eric Dumazet @ 2011-09-19 20:46 UTC (permalink / raw)
To: Maciej Żenczykowski; +Cc: David S. Miller, netdev, MuraliRaja Muniraju
In-Reply-To: <CANP3RGdxYg0Utfyrqfwoj+ojfCD+ZYJTa91nzPSdWBznZWKHaA@mail.gmail.com>
Le lundi 19 septembre 2011 à 13:39 -0700, Maciej Żenczykowski a écrit :
> The first hunk was for consistency - to always free in exit path. The
> second hunk is where the lockdep bug is.
>
> LOCKDEP gives the following (it's pretty rare):
>
> [ 90.543085] =======================================================
> [ 90.544012] [ INFO: possible circular locking dependency detected ]
> [ 90.544012] 2.6.34-smp-DEV #70
> [ 90.544012] -------------------------------------------------------
> [ 90.544012] swapper/0 is trying to acquire lock:
> [ 90.544012] (&tbl->lock){++--..}, at: [<ffffffff813c106d>]
> neigh_lookup+0x42/0xbf
> [ 90.544012]
> [ 90.544012] but task is already holding lock:
> [ 90.544012] (&(&rt_hash_locks[i])->rlock){+.-...}, at:
> [<ffffffff813db663>] rt_intern_hash+0xf2/0x3ad
> [ 90.544012]
> [ 90.544012] which lock already depends on the new lock.
> [ 90.544012]
> [ 90.544012]
> [ 90.544012] the existing dependency chain (in reverse order) is:
> [ 90.544012]
> [ 90.544012] -> #2 (&(&rt_hash_locks[i])->rlock){+.-...}:
> [ 90.544012] [<ffffffff810a4910>] __lock_acquire+0xb3b/0xcda
> [ 90.544012] [<ffffffff810a4b72>] lock_acquire+0xc3/0xe9
> [ 90.544012] [<ffffffff81430d66>] _raw_spin_lock_bh+0x36/0x45
> [ 90.544012] [<ffffffff813d9659>] rt_dst_release+0x4a/0x8d
> [ 90.544012] [<ffffffff813bee34>] dst_release+0x5d/0x66
> [ 90.544012] [<ffffffff813af24e>] skb_release_head_state+0x1f/0xa5
> [ 90.544012] [<ffffffff813aefec>] __kfree_skb+0x16/0x87
> [ 90.544012] [<ffffffff813af101>] kfree_skb+0x72/0x7a
> [ 90.544012] [<ffffffff813c06f9>] __neigh_event_send+0x126/0x176
> [ 90.544012] [<ffffffff813c2c1b>] neigh_resolve_output+0x7f/0x267
> [ 90.544012] [<ffffffff813e3057>] ip_finish_output2+0x1f2/0x221
> [ 90.544012] [<ffffffff813e30ea>] ip_finish_output+0x64/0x66
> [ 90.544012] [<ffffffff813e3200>] NF_HOOK_COND.clone.1+0x41/0x45
> [ 90.544012] [<ffffffff813e3277>] ip_output+0x73/0x75
> [ 90.544012] [<ffffffff813e1524>] dst_output+0x10/0x12
> [ 90.544012] [<ffffffff813e349f>] ip_local_out+0x23/0x27
> [ 90.544012] [<ffffffff813e378a>] ip_push_pending_frames+0x2e7/0x348
> [ 90.544012] [<ffffffff81401a13>] udp_push_pending_frames+0x2dc/0x35c
> [ 90.544012] [<ffffffff8140314e>] udp_sendmsg+0x628/0x763
> [ 90.544012] [<ffffffff81409933>] inet_sendmsg+0x58/0x61
> [ 90.544012] [<ffffffff813a726f>] __sock_sendmsg+0x5e/0x69
> [ 90.544012] [<ffffffff813a7737>] sock_sendmsg+0xa8/0xc1
> [ 90.544012] [<ffffffff813a79d9>] sys_sendmsg+0x1da/0x241
> [ 90.544012] [<ffffffff813cb482>] compat_sys_sendmsg+0x14/0x16
> [ 90.544012] [<ffffffff813cc081>] compat_sys_socketcall+0x13b/0x16c
> [ 90.544012] [<ffffffff81059687>] sysenter_dispatch+0x7/0x2c
> [ 90.544012]
> [ 90.544012] -> #1 (&n->lock){++--..}:
> [ 90.544012] [<ffffffff810a4910>] __lock_acquire+0xb3b/0xcda
> [ 90.544012] [<ffffffff810a4b72>] lock_acquire+0xc3/0xe9
> [ 90.544012] [<ffffffff81430e81>] _raw_write_lock+0x31/0x40
> [ 90.544012] [<ffffffff813c16fb>] neigh_periodic_work+0xae/0x196
> [ 90.544012] [<ffffffff8108a8ca>] worker_thread+0x1fb/0x2f1
> [ 90.544012] [<ffffffff8108e099>] kthread+0x7f/0x87
> [ 90.544012] [<ffffffff81032a94>] kernel_thread_helper+0x4/0x10
> [ 90.544012]
> [ 90.544012] -> #0 (&tbl->lock){++--..}:
> [ 90.544012] [<ffffffff810a47ba>] __lock_acquire+0x9e5/0xcda
> [ 90.544012] [<ffffffff810a4b72>] lock_acquire+0xc3/0xe9
> [ 90.544012] [<ffffffff81430ffa>] _raw_read_lock_bh+0x39/0x48
> [ 90.544012] [<ffffffff813c106d>] neigh_lookup+0x42/0xbf
> [ 90.544012] [<ffffffff81405067>]
> __neigh_lookup_errno.clone.0+0x24/0x40
> [ 90.544012] [<ffffffff814054b2>] arp_bind_neighbour+0x4c/0x65
> [ 90.544012] [<ffffffff813db815>] rt_intern_hash+0x2a4/0x3ad
> [ 90.544012] [<ffffffff813dc054>] ip_route_output_slow+0x6ec/0x739
> [ 90.544012] [<ffffffff813dc574>] __ip_route_output_key+0x1bd/0x1c9
> [ 90.544012] [<ffffffff81406f45>] icmp_send+0x2bf/0x3ca
> [ 90.544012] [<ffffffff813d9739>] ipv4_link_failure+0x22/0x5c
> [ 90.544012] [<ffffffff81404acd>] arp_error_report+0x31/0x3d
> [ 90.544012] [<ffffffff813c1172>] neigh_invalidate+0x88/0xa3
> [ 90.544012] [<ffffffff813c2a1b>] neigh_timer_handler+0x1a8/0x27f
> [ 90.544012] [<ffffffff8108087a>] run_timer_softirq+0x219/0x2e3
> [ 90.544012] [<ffffffff8107910e>] __do_softirq+0xf7/0x1cb
> [ 90.544012] [<ffffffff81032b8c>] call_softirq+0x1c/0x3e
> [ 90.544012] [<ffffffff81034615>] do_softirq+0x3d/0x85
> [ 90.544012] [<ffffffff81078d49>] irq_exit+0x4a/0x8c
> [ 90.544012] [<ffffffff8143708c>] smp_apic_timer_interrupt+0x99/0xa7
> [ 90.544012] [<ffffffff81032653>] apic_timer_interrupt+0x13/0x20
> [ 90.544012] [<ffffffff81030d92>] cpu_idle+0x5c/0x79
> [ 90.544012] [<ffffffff8142213f>] rest_init+0xc3/0xca
> [ 90.544012] [<ffffffff81b47d77>] start_kernel+0x3e2/0x3ed
> [ 90.544012] [<ffffffff81b4729f>] x86_64_start_reservations+0xaf/0xb3
> [ 90.544012] [<ffffffff81b47393>] x86_64_start_kernel+0xf0/0xf7
> [ 90.544012]
> [ 90.544012] other info that might help us debug this:
> [ 90.544012]
> [ 90.544012] 3 locks held by swapper/0:
> [ 90.544012] #0: (&n->timer){+.-...}, at: [<ffffffff810807e8>]
> run_timer_softirq+0x187/0x2e3
> [ 90.544012] #1: (slock-AF_INET){+.-...}, at: [<ffffffff814063d3>]
> icmp_xmit_lock+0x35/0x47
> [ 90.544012] #2: (&(&rt_hash_locks[i])->rlock){+.-...}, at:
> [<ffffffff813db663>] rt_intern_hash+0xf2/0x3ad
> [ 90.544012]
> [ 90.544012] stack backtrace:
> [ 90.544012] Pid: 0, comm: swapper Not tainted 2.6.34-smp-DEV #70
> [ 90.544012] Call Trace:
> [ 90.544012] <IRQ> [<ffffffff810a39c0>] print_circular_bug+0xa8/0xb7
> [ 90.544012] [<ffffffff810a47ba>] __lock_acquire+0x9e5/0xcda
> [ 90.544012] [<ffffffff813c106d>] ? neigh_lookup+0x42/0xbf
> [ 90.544012] [<ffffffff810a4b72>] lock_acquire+0xc3/0xe9
> [ 90.544012] [<ffffffff813c106d>] ? neigh_lookup+0x42/0xbf
> [ 90.544012] [<ffffffff81430ffa>] _raw_read_lock_bh+0x39/0x48
> [ 90.544012] [<ffffffff813c106d>] ? neigh_lookup+0x42/0xbf
> [ 90.544012] [<ffffffff813c106d>] neigh_lookup+0x42/0xbf
> [ 90.544012] [<ffffffff81405067>] __neigh_lookup_errno.clone.0+0x24/0x40
> [ 90.544012] [<ffffffff814054b2>] arp_bind_neighbour+0x4c/0x65
> [ 90.544012] [<ffffffff813db663>] ? rt_intern_hash+0xf2/0x3ad
> [ 90.544012] [<ffffffff813db815>] rt_intern_hash+0x2a4/0x3ad
> [ 90.544012] [<ffffffff813dc054>] ip_route_output_slow+0x6ec/0x739
> [ 90.544012] [<ffffffff81078f49>] ? _local_bh_enable_ip+0xc1/0xc7
> [ 90.544012] [<ffffffff813dc574>] __ip_route_output_key+0x1bd/0x1c9
> [ 90.544012] [<ffffffff81406f45>] icmp_send+0x2bf/0x3ca
> [ 90.544012] [<ffffffff813c2800>] ? neigh_event_ns+0x2f/0xa2
> [ 90.544012] [<ffffffff813d9739>] ipv4_link_failure+0x22/0x5c
> [ 90.544012] [<ffffffff81404acd>] arp_error_report+0x31/0x3d
> [ 90.544012] [<ffffffff813c1172>] neigh_invalidate+0x88/0xa3
> [ 90.544012] [<ffffffff813c2a1b>] neigh_timer_handler+0x1a8/0x27f
> [ 90.544012] [<ffffffff8108087a>] run_timer_softirq+0x219/0x2e3
> [ 90.544012] [<ffffffff810807e8>] ? run_timer_softirq+0x187/0x2e3
> [ 90.544012] [<ffffffff8109158d>] ? __run_hrtimer+0xf4/0x132
> [ 90.544012] [<ffffffff813c2873>] ? neigh_timer_handler+0x0/0x27f
> [ 90.544012] [<ffffffff8107908d>] ? __do_softirq+0x76/0x1cb
> [ 90.544012] [<ffffffff8107910e>] __do_softirq+0xf7/0x1cb
> [ 90.544012] [<ffffffff8109f74a>] ? tick_program_event+0x2a/0x2c
> [ 90.544012] [<ffffffff81032b8c>] call_softirq+0x1c/0x3e
> [ 90.544012] [<ffffffff81034615>] do_softirq+0x3d/0x85
> [ 90.544012] [<ffffffff81078d49>] irq_exit+0x4a/0x8c
> [ 90.544012] [<ffffffff8143708c>] smp_apic_timer_interrupt+0x99/0xa7
> [ 90.544012] [<ffffffff81032653>] apic_timer_interrupt+0x13/0x20
> [ 90.544012] <EOI> [<ffffffff81039700>] ? mwait_idle+0x85/0x92
> [ 90.544012] [<ffffffff810396f7>] ? mwait_idle+0x7c/0x92
> [ 90.544012] [<ffffffff81030d92>] cpu_idle+0x5c/0x79
> [ 90.544012] [<ffffffff8142213f>] rest_init+0xc3/0xca
> [ 90.544012] [<ffffffff8142207c>] ? rest_init+0x0/0xca
> [ 90.544012] [<ffffffff81b47d77>] start_kernel+0x3e2/0x3ed
> [ 90.544012] [<ffffffff81b4729f>] x86_64_start_reservations+0xaf/0xb3
> [ 90.544012] [<ffffffff81b47393>] x86_64_start_kernel+0xf0/0xf7
>
> At some point in the past of the lifetime of this kernel we grabbed
> exactly the following 3 locks in the following order (where the first
> 2 were still held while we grabbed the 3rd):
> (&tbl->lock){++--..} => (&n->lock){++--..} =>
> (&(&rt_hash_locks[i])->rlock){+.-...}
>
> Now, we have grabbed the first three (are still holding them and are
> trying to grab the fourth) of these locks in this order:
> (&n->timer){+.-...} => (slock-AF_INET){+.-...} =>
> (&(&rt_hash_locks[i])->rlock){+.-...} => (&tbl->lock){++--..}
>
> We're complaining that this 4th lock is being grabbed after the 3rd,
> when previously it was the 1st before the 3rd - we've apparently
> reversed lock ordering...
Hmm
What exact kernel version is it ?
^ permalink raw reply
* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: David Miller @ 2011-09-19 20:56 UTC (permalink / raw)
To: bhutchings; +Cc: alexander.h.duyck, jeffrey.t.kirsher, netdev, gospo
In-Reply-To: <1316448352.2764.27.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 19 Sep 2011 17:05:52 +0100
> But tx_max_coalesced_frames_irq is not supposed to be a work limit (and
> such a work limit doesn't seem useful in the absence of NAPI). As I
> understand it, it is supposed to be an alternate moderation value for
> the hardware to use if a frame is sent while the IRQ handler is running.
Exactly, the ethtool settings modify what the hardware interrupt mechanisms
do, ragardless of whether those hardware interrupts trigger NAPI or not.
And this is precisely what we want, because optimal behavior of NAPI
absoulutely depends upon having the interrupt moderated in hardware
at least a little bit.
^ permalink raw reply
* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: David Miller @ 2011-09-19 20:57 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: alexander.h.duyck, netdev, gospo
In-Reply-To: <1316246677-8830-12-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sat, 17 Sep 2011 01:04:35 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This change is meant to make the NAPI budget limits for transmit
> adjustable. By doing this it is possible to tune the value for optimal
> performance with applications such as routing.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
As Ben and I have mentioned, this change is not acceptable.
Ethtool settings for "hardware interrupt" coalescing and mitigation
should have no effect on NAPI behavior.
^ permalink raw reply
* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: David Miller @ 2011-09-19 21:00 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: bhutchings, jeffrey.t.kirsher, netdev, gospo
In-Reply-To: <4E776E92.6090303@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Mon, 19 Sep 2011 09:32:18 -0700
> The fact is ixgbe has been using this parameter this way for over 2
> years now and the main goal of this patch was just to synchronize how
> things work on igb and ixgbe.
>
> Our hardware doesn't have a mechanism for firing an interrupt after X
> number of frames so instead we simply have modified things so that we
> will only process X number of frames and then fire another
> interrupt/poll if needed. As such we aren't that far out of
> compliance with the meaning of how this parameter is supposed to be
> used.
All I can say is this was a huge mistake you therefore need to revert
the IXGBE change, these ethtool settings are not for changing NAPI or
software interrupt behavior.
And if you guys plan to be difficult on this and refuse to remove the
IXGBE bits, I'm letting you guys know ahead of time that I'll do it
for you.
If the hardware can't support this facility, neither should these
ethtool hooks, because the whole point is to avoid hardware interrupts
from firing using these parameters.
Propose new mechanisms to control NAPI behavior if you want.
^ permalink raw reply
* Re: [PATCH] net: fix lockdep issue in __neigh_event_send
From: Eric Dumazet @ 2011-09-19 21:03 UTC (permalink / raw)
To: Maciej Żenczykowski; +Cc: David S. Miller, netdev, MuraliRaja Muniraju
In-Reply-To: <1316465182.2455.10.camel@edumazet-laptop>
Le lundi 19 septembre 2011 à 22:46 +0200, Eric Dumazet a écrit :
> Le lundi 19 septembre 2011 à 13:39 -0700, Maciej Żenczykowski a écrit :
> > [ 90.544012] the existing dependency chain (in reverse order) is:
> > [ 90.544012]
> > [ 90.544012] -> #2 (&(&rt_hash_locks[i])->rlock){+.-...}:
> > [ 90.544012] [<ffffffff810a4910>] __lock_acquire+0xb3b/0xcda
> > [ 90.544012] [<ffffffff810a4b72>] lock_acquire+0xc3/0xe9
> > [ 90.544012] [<ffffffff81430d66>] _raw_spin_lock_bh+0x36/0x45
> > [ 90.544012] [<ffffffff813d9659>] rt_dst_release+0x4a/0x8d
rt_dst_release() again...
> > [ 90.544012] [<ffffffff813bee34>] dst_release+0x5d/0x66
> > [ 90.544012] [<ffffffff813af24e>] skb_release_head_state+0x1f/0xa5
> > [ 90.544012] [<ffffffff813aefec>] __kfree_skb+0x16/0x87
> > [ 90.544012] [<ffffffff813af101>] kfree_skb+0x72/0x7a
> > [ 90.544012] [<ffffffff813c06f9>] __neigh_event_send+0x126/0x176
> >
> Hmm
>
> What exact kernel version is it ?
>
>
Just to say what I already said to Murali raja Muniraju one week ago :
To my knowledge, no linux pristine linux kernel has this bug.
dst_release() is lockless.
So could you explain why its so important we add this 'bugfix' if it
only applies to a Google kernel ?
Anything I missed from my previous analysis ?
Thanks !
^ permalink raw reply
* Re: pull request: wireless-next 2011-09-19
From: David Miller @ 2011-09-19 21:11 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20110919203639.GF2608@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Mon, 19 Sep 2011 16:36:39 -0400
> Here is another big batch of updates intended for 3.2 -- still
> clearing-out the backlog...
>
> This round includes lots of updates to ath9k, b43, iwlagn, and rt2x00.
> Some cleanups go to mac80211, along with a number of mesh-mode fixes
> from Javier.
>
> Please let me know if there are problems!
What about the iwl build failure reported by Eric Dumazet?
If that's not handled here, I want that fixed before we add even
more regressions :-)
^ permalink raw reply
* Re: [net-next 01/13] ixgb: eliminate checkstack warnings
From: Jesse Brandeburg @ 2011-09-19 21:36 UTC (permalink / raw)
To: Joe Perches
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com
In-Reply-To: <1316249007.1610.13.camel@Joe-Laptop>
On Sat, 17 Sep 2011 01:43:26 -0700
Joe Perches <joe@perches.com> wrote:
> On Sat, 2011-09-17 at 01:04 -0700, Jeff Kirsher wrote:
> > From: Jesse Brandeburg <jesse.brandeburg@intel.com>
> > Really trivial fix, use kzalloc/kree instead of stack space.
>
> Some more trivialities...
>
> > diff --git a/drivers/net/ethernet/intel/ixgb/ixgb_main.c
> > b/drivers/net/ethernet/intel/ixgb/ixgb_main.c\
> []
> > @@ -1120,8 +1120,12 @@ ixgb_set_multi(struct net_device *netdev)
> > rctl |= IXGB_RCTL_MPE;
> > IXGB_WRITE_REG(hw, RCTL, rctl);
> > } else {
> > - u8 mta[IXGB_MAX_NUM_MULTICAST_ADDRESSES *
> > - IXGB_ETH_LENGTH_OF_ADDRESS];
> > + u8 *mta = kzalloc(IXGB_MAX_NUM_MULTICAST_ADDRESSES
> > *
> > + IXGB_ETH_LENGTH_OF_ADDRESS,
> > GFP_KERNEL);
>
> This doesn't need to be kzalloc as every byte is overwritten.
> It should be kmalloc.
done, V2 on its way
> Maybe delete the #define IXGB_ETH_LENGTH_OF_ADDRESS and
> sed 's/\bIXGB_ETH_LENGTH_OF_ADDRESS\b/ETH_ALEN/g' ?
done
> Perhaps this loop could be clearer without the multiply:
>
> i = 0;
> netdev_for_each_mc_addr(ha, netdev)
> memcpy(&mta[i++ * IXGB_ETH_LENGTH_OF_ADDRESS],
> ha->addr, IXGB_ETH_LENGTH_OF_ADDRESS);
>
> Perhaps:
>
> u8 *addr = mta;
> netdev_for_each_mc_addr(ha, netdev) {
> memcpy(addr, ha->addr, ETH_ALEN);
> addr += ETH_ALEN;
> }
done, but because of the nature of the changes being code flow, I'm
going to retest through our lab. V2 will hopefully be at the list
shortly.
Thanks for the feedback,
Jesse
^ permalink raw reply
* Re: [PATCH v2 net-next] af_unix: dont send SCM_CREDENTIALS by default
From: Tim Chen @ 2011-09-19 21:39 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, zheng.z.yan, yanzheng, netdev, sfr, jirislaby,
sedat.dilek, alex.shi, Valdis.Kletnieks
In-Reply-To: <1316447547.2539.34.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Mon, 2011-09-19 at 17:52 +0200, Eric Dumazet wrote:
> Since commit 7361c36c5224 (af_unix: Allow credentials to work across
> user and pid namespaces) af_unix performance dropped a lot.
>
> This is because we now take a reference on pid and cred in each write(),
> and release them in read(), usually done from another process,
> eventually from another cpu. This triggers false sharing.
>
> # Events: 154K cycles
> #
> # Overhead Command Shared Object Symbol
> # ........ ....... .................. .........................
> #
> 10.40% hackbench [kernel.kallsyms] [k] put_pid
> 8.60% hackbench [kernel.kallsyms] [k] unix_stream_recvmsg
> 7.87% hackbench [kernel.kallsyms] [k] unix_stream_sendmsg
> 6.11% hackbench [kernel.kallsyms] [k] do_raw_spin_lock
> 4.95% hackbench [kernel.kallsyms] [k] unix_scm_to_skb
> 4.87% hackbench [kernel.kallsyms] [k] pid_nr_ns
> 4.34% hackbench [kernel.kallsyms] [k] cred_to_ucred
> 2.39% hackbench [kernel.kallsyms] [k] unix_destruct_scm
> 2.24% hackbench [kernel.kallsyms] [k] sub_preempt_count
> 1.75% hackbench [kernel.kallsyms] [k] fget_light
> 1.51% hackbench [kernel.kallsyms] [k]
> __mutex_lock_interruptible_slowpath
> 1.42% hackbench [kernel.kallsyms] [k] sock_alloc_send_pskb
>
>
> This patch includes SCM_CREDENTIALS information in a af_unix message/skb
> only if requested by the sender, [man 7 unix for details how to include
> ancillary data using sendmsg() system call]
>
> Note: This might break buggy applications that expected SCM_CREDENTIAL
> from an unaware write() system call, and receiver not using SO_PASSCRED
> socket option.
>
> If SOCK_PASSCRED is set on source or destination socket, we still
> include credentials for mere write() syscalls.
>
> Performance boost in hackbench : more than 50% gain on a 16 thread
> machine (2 quad-core cpus, 2 threads per core)
>
> hackbench 20 thread 2000
>
> 4.228 sec instead of 9.102 sec
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
Do we have to worry about the case where peer socket changes its flag
to SOCK_PASSCRED while packets are in flight? If there isn't such
pathological use case, the patch looks fine to me.
Acked-by: Tim Chen <tim.c.chen@linux.intel.com>
^ permalink raw reply
* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: Alexander Duyck @ 2011-09-19 22:27 UTC (permalink / raw)
To: David Miller; +Cc: bhutchings, jeffrey.t.kirsher, netdev, gospo
In-Reply-To: <20110919.170033.344802441047363137.davem@davemloft.net>
On 09/19/2011 02:00 PM, David Miller wrote:
> From: Alexander Duyck<alexander.h.duyck@intel.com>
> Date: Mon, 19 Sep 2011 09:32:18 -0700
>> The fact is ixgbe has been using this parameter this way for over 2
>> years now and the main goal of this patch was just to synchronize how
>> things work on igb and ixgbe.
>>
>> Our hardware doesn't have a mechanism for firing an interrupt after X
>> number of frames so instead we simply have modified things so that we
>> will only process X number of frames and then fire another
>> interrupt/poll if needed. As such we aren't that far out of
>> compliance with the meaning of how this parameter is supposed to be
>> used.
> All I can say is this was a huge mistake you therefore need to revert
> the IXGBE change, these ethtool settings are not for changing NAPI or
> software interrupt behavior.
>
> And if you guys plan to be difficult on this and refuse to remove the
> IXGBE bits, I'm letting you guys know ahead of time that I'll do it
> for you.
>
> If the hardware can't support this facility, neither should these
> ethtool hooks, because the whole point is to avoid hardware interrupts
> from firing using these parameters.
>
> Propose new mechanisms to control NAPI behavior if you want.
I'll remove the ixgbe code if that is what you want. It may be a month
or so before I can get to it though since I am slammed with work so if
you are in a hurry for it you might want to work with Jeff Kirsher to
have the code removed.
As far as this current patch goes I honestly don't have the time to add
or rewrite yet another ethtool interface so I will probably just see
about dropping the ethtool portion of this patch and update the
description in order to make it acceptable.
Thanks,
Alex
^ permalink raw reply
* [PATCH] intel: Convert <FOO>_LENGTH_OF_ADDRESS to ETH_ALEN
From: Joe Perches @ 2011-09-19 22:28 UTC (permalink / raw)
To: Jesse Brandeburg
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com
In-Reply-To: <20110919143629.00007675@unknown>
Use the normal #defines not module specific ones.
Signed-off-by: Joe Perches <joe@perches.com>
---
Here are the other, not ixgb uses of LENGTH_OF_ADDRESS
converted to ETH_ALEN. Compile tested allyesconfig only.
drivers/net/ethernet/intel/e1000/e1000_hw.h | 1 -
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 2 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 8 +++-----
drivers/net/ethernet/intel/ixgbevf/defines.h | 1 -
drivers/net/ethernet/intel/ixgbevf/vf.c | 4 ++--
5 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_hw.h b/drivers/net/ethernet/intel/e1000/e1000_hw.h
index 5c9a840..cf7e3c0 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_hw.h
+++ b/drivers/net/ethernet/intel/e1000/e1000_hw.h
@@ -448,7 +448,6 @@ void e1000_io_write(struct e1000_hw *hw, unsigned long port, u32 value);
#define E1000_DEV_ID_INTEL_CE4100_GBE 0x2E6E
#define NODE_ADDRESS_SIZE 6
-#define ETH_LENGTH_OF_ADDRESS 6
/* MAC decode size is 128K - This is the size of BAR0 */
#define MAC_DECODE_SIZE (128 * 1024)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index d99d01e..29e092c 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -363,7 +363,7 @@ static int ixgbe_rcv_msg_from_vf(struct ixgbe_adapter *adapter, u32 vf)
/* reply to reset with ack and vf mac address */
msgbuf[0] = IXGBE_VF_RESET | IXGBE_VT_MSGTYPE_ACK;
- memcpy(new_mac, vf_mac, IXGBE_ETH_LENGTH_OF_ADDRESS);
+ memcpy(new_mac, vf_mac, ETH_ALEN);
/*
* Piggyback the multicast filter type so VF can compute the
* correct vectors
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
index 9f618ee..ef34606 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
@@ -1699,8 +1699,6 @@ enum {
#define IXGBE_NVM_POLL_WRITE 1 /* Flag for polling for write complete */
#define IXGBE_NVM_POLL_READ 0 /* Flag for polling for read complete */
-#define IXGBE_ETH_LENGTH_OF_ADDRESS 6
-
#define IXGBE_EEPROM_PAGE_SIZE_MAX 128
#define IXGBE_EEPROM_RD_BUFFER_MAX_COUNT 512 /* EEPROM words # read in burst */
#define IXGBE_EEPROM_WR_BUFFER_MAX_COUNT 256 /* EEPROM words # wr in burst */
@@ -2737,9 +2735,9 @@ struct ixgbe_eeprom_info {
struct ixgbe_mac_info {
struct ixgbe_mac_operations ops;
enum ixgbe_mac_type type;
- u8 addr[IXGBE_ETH_LENGTH_OF_ADDRESS];
- u8 perm_addr[IXGBE_ETH_LENGTH_OF_ADDRESS];
- u8 san_addr[IXGBE_ETH_LENGTH_OF_ADDRESS];
+ u8 addr[ETH_ALEN];
+ u8 perm_addr[ETH_ALEN];
+ u8 san_addr[ETH_ALEN];
/* prefix for World Wide Node Name (WWNN) */
u16 wwnn_prefix;
/* prefix for World Wide Port Name (WWPN) */
diff --git a/drivers/net/ethernet/intel/ixgbevf/defines.h b/drivers/net/ethernet/intel/ixgbevf/defines.h
index 78abb6f..2eb89cb 100644
--- a/drivers/net/ethernet/intel/ixgbevf/defines.h
+++ b/drivers/net/ethernet/intel/ixgbevf/defines.h
@@ -35,7 +35,6 @@
#define IXGBE_VF_IRQ_CLEAR_MASK 7
#define IXGBE_VF_MAX_TX_QUEUES 1
#define IXGBE_VF_MAX_RX_QUEUES 1
-#define IXGBE_ETH_LENGTH_OF_ADDRESS 6
/* Link speed */
typedef u32 ixgbe_link_speed;
diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.c b/drivers/net/ethernet/intel/ixgbevf/vf.c
index aa3682e..21533e3 100644
--- a/drivers/net/ethernet/intel/ixgbevf/vf.c
+++ b/drivers/net/ethernet/intel/ixgbevf/vf.c
@@ -108,7 +108,7 @@ static s32 ixgbevf_reset_hw_vf(struct ixgbe_hw *hw)
if (msgbuf[0] != (IXGBE_VF_RESET | IXGBE_VT_MSGTYPE_ACK))
return IXGBE_ERR_INVALID_MAC_ADDR;
- memcpy(hw->mac.perm_addr, addr, IXGBE_ETH_LENGTH_OF_ADDRESS);
+ memcpy(hw->mac.perm_addr, addr, ETH_ALEN);
hw->mac.mc_filter_type = msgbuf[IXGBE_VF_MC_TYPE_WORD];
return 0;
@@ -211,7 +211,7 @@ static s32 ixgbevf_mta_vector(struct ixgbe_hw *hw, u8 *mc_addr)
**/
static s32 ixgbevf_get_mac_addr_vf(struct ixgbe_hw *hw, u8 *mac_addr)
{
- memcpy(mac_addr, hw->mac.perm_addr, IXGBE_ETH_LENGTH_OF_ADDRESS);
+ memcpy(mac_addr, hw->mac.perm_addr, ETH_ALEN);
return 0;
}
^ permalink raw reply related
* Re: [PATCH 3/4] net/fec: set phy_speed to the optimal frequency 2.5 MHz
From: Troy Kisky @ 2011-09-19 22:39 UTC (permalink / raw)
To: Shawn Guo; +Cc: netdev, David S. Miller, linux-arm-kernel, patches
In-Reply-To: <1316346852-17090-4-git-send-email-shawn.guo@linaro.org>
On 9/18/2011 4:54 AM, Shawn Guo wrote:
> With the unnecessary 1 bit left-shift on fep->phy_speed during the
> calculation, the phy_speed always runs at the half frequency of the
> optimal one 2.5 MHz.
>
> The patch removes that 1 bit left-shift to get the optimal phy_speed.
>
> Signed-off-by: Shawn Guo<shawn.guo@linaro.org>
> ---
> drivers/net/fec.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/fec.c b/drivers/net/fec.c
> index 5ef0e34..04206e4 100644
> --- a/drivers/net/fec.c
> +++ b/drivers/net/fec.c
> @@ -1007,7 +1007,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
> /*
> * Set MII speed to 2.5 MHz (= clk_get_rate() / 2 * phy_speed)
> */
> - fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000)<< 1;
> + fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000);
> writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
>
> fep->mii_bus = mdiobus_alloc();
Do you need to round up to an even value? Is the hardware documentation
wrong?
Does this need a quirk? What boards has this been verified to fix?
Thanks
Troy
^ permalink raw reply
* Re: [PATCH] intel: Convert <FOO>_LENGTH_OF_ADDRESS to ETH_ALEN
From: Jeff Kirsher @ 2011-09-19 23:33 UTC (permalink / raw)
To: Joe Perches
Cc: Brandeburg, Jesse, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com
In-Reply-To: <1316471288.22881.3.camel@Joe-Laptop>
[-- Attachment #1: Type: text/plain, Size: 708 bytes --]
On Mon, 2011-09-19 at 15:28 -0700, Joe Perches wrote:
> Use the normal #defines not module specific ones.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> Here are the other, not ixgb uses of LENGTH_OF_ADDRESS
> converted to ETH_ALEN. Compile tested allyesconfig only.
>
> drivers/net/ethernet/intel/e1000/e1000_hw.h | 1 -
> drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 2 +-
> drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 8 +++-----
> drivers/net/ethernet/intel/ixgbevf/defines.h | 1 -
> drivers/net/ethernet/intel/ixgbevf/vf.c | 4 ++--
> 5 files changed, 6 insertions(+), 10 deletions(-)
Thanks Joe. I have added the patch to my queue.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: Jeff Kirsher @ 2011-09-19 23:36 UTC (permalink / raw)
To: Duyck, Alexander H
Cc: David Miller, bhutchings@solarflare.com, netdev@vger.kernel.org,
gospo@redhat.com
In-Reply-To: <4E77C1D4.503@intel.com>
[-- Attachment #1: Type: text/plain, Size: 2024 bytes --]
On Mon, 2011-09-19 at 15:27 -0700, Duyck, Alexander H wrote:
> On 09/19/2011 02:00 PM, David Miller wrote:
> > From: Alexander Duyck<alexander.h.duyck@intel.com>
> > Date: Mon, 19 Sep 2011 09:32:18 -0700
> >> The fact is ixgbe has been using this parameter this way for over 2
> >> years now and the main goal of this patch was just to synchronize how
> >> things work on igb and ixgbe.
> >>
> >> Our hardware doesn't have a mechanism for firing an interrupt after X
> >> number of frames so instead we simply have modified things so that we
> >> will only process X number of frames and then fire another
> >> interrupt/poll if needed. As such we aren't that far out of
> >> compliance with the meaning of how this parameter is supposed to be
> >> used.
> > All I can say is this was a huge mistake you therefore need to revert
> > the IXGBE change, these ethtool settings are not for changing NAPI or
> > software interrupt behavior.
> >
> > And if you guys plan to be difficult on this and refuse to remove the
> > IXGBE bits, I'm letting you guys know ahead of time that I'll do it
> > for you.
> >
> > If the hardware can't support this facility, neither should these
> > ethtool hooks, because the whole point is to avoid hardware interrupts
> > from firing using these parameters.
> >
> > Propose new mechanisms to control NAPI behavior if you want.
> I'll remove the ixgbe code if that is what you want. It may be a month
> or so before I can get to it though since I am slammed with work so if
> you are in a hurry for it you might want to work with Jeff Kirsher to
> have the code removed.
Alex- I will work on this to resolve the issues the Ben and Dave have
pointed out.
>
> As far as this current patch goes I honestly don't have the time to add
> or rewrite yet another ethtool interface so I will probably just see
> about dropping the ethtool portion of this patch and update the
> description in order to make it acceptable.
>
> Thanks,
>
> Alex
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: Stephen Hemminger @ 2011-09-19 23:42 UTC (permalink / raw)
To: jeffrey t kirsher
Cc: David Miller, bhutchings, netdev, gospo, Alexander H Duyck
In-Reply-To: <1316475390.2184.8.camel@jtkirshe-mobl>
I would like to see a general solution to allow configuring
napi weight. The Rx weight isn't easily configurable either.
Probably needs to be through ethtool callback since actual value range
and dev -> napi relationship is device specific.
^ permalink raw reply
* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: David Miller @ 2011-09-19 23:47 UTC (permalink / raw)
To: stephen.hemminger
Cc: jeffrey.t.kirsher, bhutchings, netdev, gospo, alexander.h.duyck
In-Reply-To: <19fca01e-5827-4e28-b12c-2b65cca96878@tahiti.vyatta.com>
From: Stephen Hemminger <stephen.hemminger@vyatta.com>
Date: Mon, 19 Sep 2011 16:42:31 -0700 (PDT)
> I would like to see a general solution to allow configuring
> napi weight. The Rx weight isn't easily configurable either.
> Probably needs to be through ethtool callback since actual value range
> and dev -> napi relationship is device specific.
Agreed, it probably has to be per-queue too.
^ permalink raw reply
* Re: MSI-X vector count on 82754L
From: Jeff Kirsher @ 2011-09-19 23:56 UTC (permalink / raw)
To: Arnaud Lacombe; +Cc: Allan, Bruce W, netdev@vger.kernel.org, Vogel, Jack
In-Reply-To: <CACqU3MUfQn_r2oJ+ptuzYhkkUoucfL_NTMnHoCa0+TouP0s0kA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2229 bytes --]
On Sun, 2011-09-18 at 22:34 -0700, Arnaud Lacombe wrote:
> [fixing address of the netdev@ list, sorry - A.]
>
> On Mon, Sep 19, 2011 at 1:31 AM, Arnaud Lacombe <lacombar@gmail.com> wrote:
> > Hi folks,
> >
> > In:
> >
> > commit 4662e82b2cb41c60826e50474dd86dd5c6372b0c
> > Author: Bruce Allan <bruce.w.allan@intel.com>
> > Date: Tue Aug 26 18:37:06 2008 -0700
> >
> > e1000e: add support for new 82574L part
> >
> > This new part has the same feature set as previous parts with the addition
> > of MSI-X support.
> >
> > Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
> >
> > MSI-X support was added to the e1000e driver, later on slightly reworked by:
> >
> > commit 8e86acd7d5968e08b3e1604e685a8c45f6fd7f40
> > Author: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > Date: Mon Aug 2 14:27:23 2010 +0000
> >
> > e1000e: Fix irq_synchronize in MSI-X case
> >
> > Based on original patch/work from Jean Delvare <jdelvare@suse.de>
> > Synchronize all IRQs when in MSI-X IRQ mode.
> >
> > Jean's original patch hard coded the sync with the 3 possible vectors,
> > this patch incorporates more flexibility for the future and aligns
> > with how igb stores the number of vectors into the adapter structure.
> >
> > CC: Jean Delvare <jdelvare@suse.de>
> > Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> > Acked-by: Bruce Allan <bruce.w.allan@intel.com>
> > Signed-off-by: David S. Miller <davem@davemloft.net>
> >
> > [It is unclear to what "Jean" does this commit log refers to, as the
> > support MSI-X was added Bruce, anyway...]
> >
> > Why only 3 vectors are used when both the product brief and the
> > datasheet advertise up to 5 MSI-X vector usable by the chip ? That is
> > 2*RX + 2*TX.
> >
> > Thanks in advance,
> > - Arnaud
> >
The e1000e driver is only a single queue driver so it does not need more
than 3 vectors, that is the reason we only use the 3 vectors.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] net: fix lockdep issue in __neigh_event_send
From: Maciej Żenczykowski @ 2011-09-20 0:01 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, netdev, MuraliRaja Muniraju
In-Reply-To: <1316466207.2455.15.camel@edumazet-laptop>
> To my knowledge, no linux pristine linux kernel has this bug.
>
> dst_release() is lockless.
You are probably right there, I missed that this was caused by some
other old crappy code we've been trying to get rid of.
> So could you explain why its so important we add this 'bugfix' if it
> only applies to a Google kernel ?
Freeing the skb later seemed to be pretty painless...
> Anything I missed from my previous analysis ?
>
> Thanks !
Probably not.
Now that the dst cache is going away this probably doesn't really
matter either way.
Maciej
^ permalink raw reply
* Re: [net-next 01/11] ixgb: convert to ndo_fix_features
From: Jeff Kirsher @ 2011-09-20 0:02 UTC (permalink / raw)
To: Michał Mirosław
Cc: davem@davemloft.net, netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <20110917132153.GA32572@rere.qmqm.pl>
[-- Attachment #1: Type: text/plain, Size: 827 bytes --]
On Sat, 2011-09-17 at 06:21 -0700, Michał Mirosław wrote:
> On Fri, Sep 16, 2011 at 07:15:42PM -0700, Jeff Kirsher wrote:
> > From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> > Private rx_csum flags are now duplicate of netdev->features &
> NETIF_F_RXCSUM.
> > Removing this needs deeper surgery.
> [...]
>
> Hmm. Looks like this patch is not complete: part removing
> get/set_flags
> from ethtool_ops is missing. I don't remember if this was included or
> not
> in the patch I sent originally. I'm attaching it now, rebased on
> current
> net-next (not tested).
>
> Best Regards,
> Michał Mirosław
>
> ---
>
> Finish conversion to unified ethtool ops: convert get_flags.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Thanks Michal, I have added the patch to my queue.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: Ben Hutchings @ 2011-09-20 0:10 UTC (permalink / raw)
To: Stephen Hemminger
Cc: jeffrey t kirsher, David Miller, netdev, gospo, Alexander H Duyck
In-Reply-To: <19fca01e-5827-4e28-b12c-2b65cca96878@tahiti.vyatta.com>
On Mon, 2011-09-19 at 16:42 -0700, Stephen Hemminger wrote:
> I would like to see a general solution to allow configuring
> napi weight. The Rx weight isn't easily configurable either.
Indeed.
> Probably needs to be through ethtool callback since actual value range
> and dev -> napi relationship is device specific.
The maximum meaningful value is device specific but I'm not sure that
really matters.
And as David said it's really a many-to-one mapping of queue -> NAPI.
At netconf we talked about having 'irq' as an attribute of each queue
but maybe we should expose NAPI contexts through sysfs and make queues
refer to them instead. NAPI contexts would be named (in the same way as
the corresponding IRQ handlers) and have irq, weight, etc.
(Still short of time to work on this myself, alas.)
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ 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