* Re: [patch] latency tracer, 2.6.15-rc7
From: Lee Revell @ 2006-01-01 8:32 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ingo Molnar, Dave Jones, Hugh Dickins, linux-kernel, NetDev
In-Reply-To: <1135991732.31111.57.camel@mindpipe>
On Fri, 2005-12-30 at 20:15 -0500, Lee Revell wrote:
> On Fri, 2005-12-30 at 17:02 -0800, Linus Torvalds wrote:
> >
> > On Fri, 30 Dec 2005, Lee Revell wrote:
> > >
> > > It seems that the networking code's use of RCU can cause 10ms+
> > > latencies:
> >
> > Hmm. Is there a big jump at the 10ms mark? Do you have a 100Hz timer
> > source?
> >
> > A latency jump at 10ms would tend to indicate a missed wakeup that
> > was "picked up" by the next timer tick.
>
> No there are no large jumps, it really seems that this was the network
> code causing an RCU callback to drop ~2K routes at once. Specifically
> RCU invokes dst_rcu_free 2085 times in a single batch
> (call_rcu_bh(&rt->u.dst.rcu_head, dst_rcu_free) is only called from
> rt_free() and rt_drop()).
>
> I have found that many of the paths in the network stack that can cause
> high latencies can be tuned via sysctls (for example
> net.ipv4.route.gc_thresh); this one may be the same.
On a related topic:
I thought I had solved the route cache flushing problem by tuning these
sysctls, but it does not seems to help.
The short version is that rt_run_flush and rt_garbage_collect can cause
15ms+ latencies when a lot of routes (up to 4096 it seems) are flushed
in one go:
$ grep "local_bh_enable (rt_run_flush)" /proc/latency_trace | wc -l
4096
$ grep "local_bh_enable (rt_garbage_collect)" /proc/latency_trace | wc
-l
4096
(rt_run_flush and rt_garbage_collect call spin_lock_bh/spin_unlock_bh
once for each flushed route so the above grep effectively counts the
number of routes flushed at once)
I reported this a year or so ago and it led to Ingo adding an option to
-rt (then called the voluntary preempt patch) to always run softirqs in
threads which makes rt_run_flush preemptible.
Anyway I thought I could work around this with mainline by tuning the
network stack to minimize the effect of route cache flushing on
scheduler latency using these sysctls to cause the route cache to be
flushed more often and/or limit the maximum size of the route cache:
$ sudo /sbin/sysctl -a | grep route
net.ipv4.route.gc_elasticity = 8
net.ipv4.route.gc_interval = 60
net.ipv4.route.gc_timeout = 300
net.ipv4.route.gc_min_interval_ms = 20
net.ipv4.route.gc_min_interval = 0
net.ipv4.route.max_size = 65536
net.ipv4.route.gc_thresh = 256
net.ipv4.route.max_delay = 10
net.ipv4.route.min_delay = 2
I tried lowering gc_min_interval_ms, gc_timeout, max_size, and gc_thresh
but rt_run_flush will still process up to 4096 (the size of the route
hash table?) routes at once.
(stop here if you don't care to interpret long latency_trace reports)
17ms+ latency caused by rt_run_flush then rt_garbage_collect processing
4096 routes:
preemption latency trace v1.1.5 on 2.6.15-rc7
--------------------------------------------------------------------
latency: 17286 us, #19154/19154, CPU#0 | (M:rt VP:0, KP:0, SP:0 HP:0)
-----------------
| task: gtk-gnutella-8581 (uid:1000 nice:0 policy:0 rt_prio:0)
-----------------
_------=> CPU#
/ _-----=> irqs-off
| / _----=> need-resched
|| / _---=> hardirq/softirq
||| / _--=> preempt-depth
|||| /
||||| delay
cmd pid ||||| time | caller
\ / ||||| \ | /
epiphany-8742 0dns8 0us : __trace_start_sched_wakeup (try_to_wake_up)
epiphany-8742 0dns8 1us : __trace_start_sched_wakeup <<...>-8581> (73 0)
epiphany-8742 0dns7 2us : preempt_schedule (__trace_start_sched_wakeup)
epiphany-8742 0dns6 2us : preempt_schedule (try_to_wake_up)
epiphany-8742 0dns5 3us : preempt_schedule (__wake_up)
epiphany-8742 0dns5 4us : preempt_schedule (ep_poll_safewake)
epiphany-8742 0dnH5 6us : do_IRQ (c011223e b 0)
epiphany-8742 0d.h. 6us : __do_IRQ (do_IRQ)
epiphany-8742 0d.h1 7us+: mask_and_ack_8259A (__do_IRQ)
epiphany-8742 0d.h. 12us : handle_IRQ_event (__do_IRQ)
epiphany-8742 0d.h. 13us : usb_hcd_irq (handle_IRQ_event)
epiphany-8742 0d.h. 13us : uhci_irq (usb_hcd_irq)
epiphany-8742 0d.h. 14us : via_driver_irq_handler (handle_IRQ_event)
epiphany-8742 0d.h. 16us : rhine_interrupt (handle_IRQ_event)
epiphany-8742 0d.h. 16us : ioread16 (rhine_interrupt)
epiphany-8742 0d.h. 17us : ioread8 (rhine_interrupt)
epiphany-8742 0d.h. 18us : iowrite16 (rhine_interrupt)
epiphany-8742 0d.h. 19us : ioread8 (rhine_interrupt)
epiphany-8742 0d.h. 20us : rhine_tx (rhine_interrupt)
epiphany-8742 0d.h1 21us : raise_softirq_irqoff (rhine_tx)
epiphany-8742 0d.h. 22us : ioread16 (rhine_interrupt)
epiphany-8742 0d.h. 23us : ioread8 (rhine_interrupt)
epiphany-8742 0d.h1 25us : note_interrupt (__do_IRQ)
epiphany-8742 0d.h1 25us : end_8259A_irq (__do_IRQ)
epiphany-8742 0d.h1 26us : enable_8259A_irq (end_8259A_irq)
epiphany-8742 0dnH5 28us : irq_exit (do_IRQ)
epiphany-8742 0dns5 28us < (2097760)
epiphany-8742 0dns4 29us : preempt_schedule (__wake_up)
epiphany-8742 0dns3 30us : preempt_schedule (sock_def_readable)
epiphany-8742 0dns2 31us : preempt_schedule (tcp_v4_rcv)
epiphany-8742 0dns1 32us : preempt_schedule (ip_local_deliver)
epiphany-8742 0dns. 33us : preempt_schedule (netif_receive_skb)
epiphany-8742 0dns. 33us : net_tx_action (__do_softirq)
epiphany-8742 0dns. 34us : __kfree_skb (net_tx_action)
epiphany-8742 0dns. 35us : sock_wfree (__kfree_skb)
epiphany-8742 0dns. 35us : kfree_skbmem (__kfree_skb)
epiphany-8742 0dns. 36us : skb_release_data (kfree_skbmem)
epiphany-8742 0dns. 37us : kfree (skb_release_data)
epiphany-8742 0dns. 38us : kmem_cache_free (kfree_skbmem)
epiphany-8742 0dn.. 39us : schedule (work_resched)
epiphany-8742 0dn.. 40us : stop_trace (schedule)
epiphany-8742 0dn.. 40us : profile_hit (schedule)
epiphany-8742 0dn.1 41us : sched_clock (schedule)
epiphany-8742 0dn.2 43us : recalc_task_prio (schedule)
epiphany-8742 0dn.2 44us : effective_prio (recalc_task_prio)
epiphany-8742 0dn.2 45us : requeue_task (schedule)
<...>-8581 0d..2 47us : __switch_to (schedule)
<...>-8581 0d..2 49us : schedule <epiphany-8742> (7d 73)
<...>-8581 0d.h2 50us : do_IRQ (c022ecf4 0 0)
<...>-8581 0d.h. 51us : __do_IRQ (do_IRQ)
<...>-8581 0d.h1 52us+: mask_and_ack_8259A (__do_IRQ)
<...>-8581 0d.h. 56us : handle_IRQ_event (__do_IRQ)
<...>-8581 0d.h. 56us : timer_interrupt (handle_IRQ_event)
<...>-8581 0d.h1 57us+: mark_offset_tsc (timer_interrupt)
<...>-8581 0d.h1 64us : do_timer (timer_interrupt)
<...>-8581 0d.h1 64us : update_wall_time (do_timer)
<...>-8581 0d.h1 65us : update_wall_time_one_tick (update_wall_time)
<...>-8581 0d.h1 66us : update_process_times (timer_interrupt)
<...>-8581 0d.h1 66us : account_system_time (update_process_times)
<...>-8581 0d.h1 67us : acct_update_integrals (account_system_time)
<...>-8581 0d.h1 69us : run_local_timers (update_process_times)
<...>-8581 0d.h1 69us : raise_softirq (run_local_timers)
<...>-8581 0d.h1 70us : scheduler_tick (update_process_times)
<...>-8581 0d.h1 71us : sched_clock (scheduler_tick)
<...>-8581 0d.h2 72us : task_timeslice (scheduler_tick)
<...>-8581 0d.h1 73us : run_posix_cpu_timers (update_process_times)
<...>-8581 0d.h1 74us : smp_local_timer_interrupt (timer_interrupt)
<...>-8581 0d.h1 75us : profile_tick (smp_local_timer_interrupt)
<...>-8581 0d.h1 76us : profile_hit (profile_tick)
<...>-8581 0d.h1 77us : note_interrupt (__do_IRQ)
<...>-8581 0d.h1 77us : end_8259A_irq (__do_IRQ)
<...>-8581 0d.h1 78us+: enable_8259A_irq (end_8259A_irq)
<...>-8581 0d.h2 80us : irq_exit (do_IRQ)
<...>-8581 0d..3 81us : do_softirq (irq_exit)
<...>-8581 0dns. 81us : __do_softirq (do_softirq)
<...>-8581 0dns. 82us : run_timer_softirq (__do_softirq)
<...>-8581 0dns. 83us : preempt_schedule (run_timer_softirq)
<...>-8581 0dns. 84us : rt_secret_rebuild (run_timer_softirq)
<...>-8581 0dns. 85us : rt_cache_flush (rt_secret_rebuild)
<...>-8581 0dns1 86us : del_timer (rt_cache_flush)
<...>-8581 0dns. 87us : local_bh_enable (rt_cache_flush)
<...>-8581 0dns. 88us : preempt_schedule (local_bh_enable)
<...>-8581 0dns. 88us : rt_run_flush (rt_cache_flush)
<...>-8581 0dns. 89us : get_random_bytes (rt_run_flush)
<...>-8581 0dns. 90us : extract_entropy (get_random_bytes)
<...>-8581 0dns. 91us : xfer_secondary_pool (extract_entropy)
<...>-8581 0dns. 92us : extract_entropy (xfer_secondary_pool)
<...>-8581 0dns. 93us : xfer_secondary_pool (extract_entropy)
<...>-8581 0dns. 94us : account (extract_entropy)
<...>-8581 0dns. 95us : preempt_schedule (account)
<...>-8581 0dns. 96us : extract_buf (extract_entropy)
<...>-8581 0dns. 97us : sha_init (extract_buf)
<...>-8581 0dns. 98us+: sha_transform (extract_buf)
<...>-8581 0dns. 106us+: __add_entropy_words (extract_buf)
<...>-8581 0dns. 108us : preempt_schedule (__add_entropy_words)
<...>-8581 0dns. 109us+: sha_transform (extract_buf)
<...>-8581 0dns. 116us : __add_entropy_words (extract_buf)
<...>-8581 0dns. 117us : preempt_schedule (__add_entropy_words)
<...>-8581 0dns. 118us+: sha_transform (extract_buf)
<...>-8581 0dns. 125us : __add_entropy_words (extract_buf)
<...>-8581 0dns. 126us : preempt_schedule (__add_entropy_words)
<...>-8581 0dns. 127us+: sha_transform (extract_buf)
<...>-8581 0dns. 134us : __add_entropy_words (extract_buf)
<...>-8581 0dns. 135us : preempt_schedule (__add_entropy_words)
<...>-8581 0dns. 136us+: sha_transform (extract_buf)
<...>-8581 0dns. 143us : __add_entropy_words (extract_buf)
<...>-8581 0dns. 144us : preempt_schedule (__add_entropy_words)
<...>-8581 0dns. 144us+: sha_transform (extract_buf)
<...>-8581 0dns. 151us : __add_entropy_words (extract_buf)
<...>-8581 0dns. 152us : preempt_schedule (__add_entropy_words)
<...>-8581 0dns. 153us+: sha_transform (extract_buf)
<...>-8581 0dns. 160us : __add_entropy_words (extract_buf)
<...>-8581 0dns. 161us : preempt_schedule (__add_entropy_words)
<...>-8581 0dns. 162us+: sha_transform (extract_buf)
<...>-8581 0dns. 169us : __add_entropy_words (extract_buf)
<...>-8581 0dns. 170us : preempt_schedule (__add_entropy_words)
<...>-8581 0dns. 171us : __add_entropy_words (extract_buf)
<...>-8581 0dns. 172us : preempt_schedule (__add_entropy_words)
<...>-8581 0dns. 173us+: sha_transform (extract_buf)
<...>-8581 0dns. 180us : __add_entropy_words (xfer_secondary_pool)
<...>-8581 0dns. 182us : preempt_schedule (__add_entropy_words)
<...>-8581 0dns. 183us : credit_entropy_store (xfer_secondary_pool)
<...>-8581 0dns. 184us : preempt_schedule (credit_entropy_store)
<...>-8581 0dns. 185us : account (extract_entropy)
<...>-8581 0dns1 186us : __wake_up (account)
<...>-8581 0dns2 186us : __wake_up_common (__wake_up)
<...>-8581 0dns1 187us : preempt_schedule (__wake_up)
<...>-8581 0dns. 188us : preempt_schedule (account)
<...>-8581 0dns. 188us : extract_buf (extract_entropy)
<...>-8581 0dns. 189us : sha_init (extract_buf)
<...>-8581 0dns. 190us+: sha_transform (extract_buf)
<...>-8581 0dns. 197us : __add_entropy_words (extract_buf)
<...>-8581 0dns. 198us : preempt_schedule (__add_entropy_words)
<...>-8581 0dns. 198us+: sha_transform (extract_buf)
<...>-8581 0dns. 205us : __add_entropy_words (extract_buf)
<...>-8581 0dns. 206us : preempt_schedule (__add_entropy_words)
<...>-8581 0dns. 207us : __add_entropy_words (extract_buf)
<...>-8581 0dns. 209us : preempt_schedule (__add_entropy_words)
<...>-8581 0dns. 209us+: sha_transform (extract_buf)
<...>-8581 0dns. 217us : local_bh_enable (rt_run_flush)
<...>-8581 0dns. 218us : preempt_schedule (local_bh_enable)
<...>-8581 0dns. 219us : call_rcu_bh (rt_run_flush)
<...>-8581 0dns. 220us : local_bh_enable (rt_run_flush)
<...>-8581 0dns. 221us : preempt_schedule (local_bh_enable)
<...>-8581 0dns. 222us : call_rcu_bh (rt_run_flush)
<...>-8581 0dns. 223us : call_rcu_bh (rt_run_flush)
<...>-8581 0dns. 224us : local_bh_enable (rt_run_flush)
<...>-8581 0dns. 225us : preempt_schedule (local_bh_enable)
<...>-8581 0dns. 226us : local_bh_enable (rt_run_flush)
<...>-8581 0dns. 227us : preempt_schedule (local_bh_enable)
[ rt_run_flush x 4096 routes ]
<...>-8581 0dns. 8763us : local_bh_enable (rt_run_flush)
<...>-8581 0dns. 8764us : preempt_schedule (local_bh_enable)
<...>-8581 0dns. 8765us : mod_timer (rt_secret_rebuild)
<...>-8581 0dns. 8766us : __mod_timer (mod_timer)
<...>-8581 0dns. 8766us : lock_timer_base (__mod_timer)
<...>-8581 0dns1 8767us : internal_add_timer (__mod_timer)
<...>-8581 0dns. 8769us+: preempt_schedule (__mod_timer)
<...>-8581 0dns. 8771us : preempt_schedule (run_timer_softirq)
<...>-8581 0dns. 8772us : tcp_delack_timer (run_timer_softirq)
[ tcp_delack_timer ... ]
<...>-8581 0dns. 8841us : preempt_schedule (tcp_delack_timer)
<...>-8581 0dns. 8842us+: preempt_schedule (run_timer_softirq)
<...>-8581 0dnH. 8845us : do_IRQ (c010dc95 b 0)
[ network irq ]
<...>-8581 0dnH. 8871us : irq_exit (do_IRQ)
<...>-8581 0dns. 8871us < (2097760)
<...>-8581 0dns. 8872us : run_timer_softirq (__do_softirq)
<...>-8581 0dns. 8873us : net_rx_action (__do_softirq)
<...>-8581 0dns. 8874us : process_backlog (net_rx_action)
<...>-8581 0dns. 8875us : netif_receive_skb (process_backlog)
<...>-8581 0dns1 8877us : packet_rcv_spkt (netif_receive_skb)
<...>-8581 0dns1 8878us : skb_clone (packet_rcv_spkt)
<...>-8581 0dns1 8878us : kmem_cache_alloc (skb_clone)
<...>-8581 0dns1 8880us : strlcpy (packet_rcv_spkt)
<...>-8581 0dns2 8881us : sk_run_filter (packet_rcv_spkt)
<...>-8581 0dns1 8882us : preempt_schedule (packet_rcv_spkt)
<...>-8581 0dns1 8883us : __kfree_skb (packet_rcv_spkt)
<...>-8581 0dns1 8884us : skb_release_data (kfree_skbmem)
<...>-8581 0dns1 8884us : kmem_cache_free (kfree_skbmem)
<...>-8581 0dns1 8885us : ip_rcv (netif_receive_skb)
<...>-8581 0dns1 8886us : ip_route_input (ip_rcv)
<...>-8581 0dns1 8887us : rt_hash_code (ip_route_input)
<...>-8581 0dns1 8888us : preempt_schedule (ip_route_input)
<...>-8581 0dns1 8889us : ip_route_input_slow (ip_route_input)
<...>-8581 0dns1 8890us : preempt_schedule (ip_route_input_slow)
<...>-8581 0dns1 8891us+: memset (ip_route_input_slow)
<...>-8581 0dns1 8893us+: fn_hash_lookup (ip_route_input_slow)
<...>-8581 0dns2 8895us : fib_semantic_match (fn_hash_lookup)
<...>-8581 0dns1 8897us : preempt_schedule (fn_hash_lookup)
<...>-8581 0dns1 8899us : fib_validate_source (ip_route_input_slow)
<...>-8581 0dns1 8900us : memset (fib_validate_source)
<...>-8581 0dns1 8901us : preempt_schedule (fib_validate_source)
<...>-8581 0dns1 8902us : fn_hash_lookup (fib_validate_source)
<...>-8581 0dns1 8903us : preempt_schedule (fn_hash_lookup)
<...>-8581 0dns1 8904us : fn_hash_lookup (fib_validate_source)
<...>-8581 0dns2 8906us : fib_semantic_match (fn_hash_lookup)
<...>-8581 0dns1 8907us : preempt_schedule (fn_hash_lookup)
<...>-8581 0dns1 8908us : __fib_res_prefsrc (fib_validate_source)
<...>-8581 0dns1 8909us : inet_select_addr (__fib_res_prefsrc)
<...>-8581 0dns1 8910us+: preempt_schedule (inet_select_addr)
<...>-8581 0dns1 8912us : dst_alloc (ip_route_input_slow)
<...>-8581 0dns1 8913us+: rt_garbage_collect (dst_alloc)
<...>-8581 0dns1 8916us : local_bh_enable (rt_garbage_collect)
<...>-8581 0dns1 8917us : preempt_schedule (local_bh_enable)
<...>-8581 0dns1 8918us : local_bh_enable (rt_garbage_collect)
<...>-8581 0dns1 8919us : preempt_schedule (local_bh_enable)
[ rt_garbage_collect x 4096 routes ]
<...>-8581 0dns1 16460us : local_bh_enable (rt_garbage_collect)
<...>-8581 0dns1 16461us : preempt_schedule (local_bh_enable)
<...>-8581 0dns1 16462us+: kmem_cache_alloc (dst_alloc)
<...>-8581 0dns1 16468us : preempt_schedule (ip_route_input_slow)
<...>-8581 0dns1 16469us : rt_hash_code (ip_route_input_slow)
<...>-8581 0dns1 16470us : rt_intern_hash (ip_route_input_slow)
<...>-8581 0dns1 16472us : local_bh_enable (rt_intern_hash)
<...>-8581 0dns1 16473us+: preempt_schedule (local_bh_enable)
<...>-8581 0dns1 16476us+: ip_local_deliver (ip_rcv)
[ ~1ms more network softirqs ]
<...>-8581 0dns. 17278us+: preempt_schedule (rcu_check_quiescent_state)
<...>-8581 0dn.2 17280us < (2097760)
<...>-8581 0dn.1 17281us : preempt_schedule (schedule)
<...>-8581 0dn.1 17282us : trace_stop_sched_switched (schedule)
<...>-8581 0dn.2 17283us+: trace_stop_sched_switched <<...>-8581> (73 0)
<...>-8581 0dn.2 17285us : trace_stop_sched_switched (schedule)
Lee
^ permalink raw reply
* Your Password
From: hostmaster @ 2005-12-31 7:31 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 111 bytes --]
Protected message is attached!
***** Go to: http://www.uni-paderborn.de
***** Email: postman@uni-paderborn.de
[-- Attachment #2: reg_pass-data.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Your Password
From: Admin @ 2005-12-31 7:08 UTC (permalink / raw)
To: Z-Account
[-- Attachment #1: Type: text/plain, Size: 117 bytes --]
Account and Password Information are attached!
***** Go to: http://www.freebsd.org
***** Email: postman@freebsd.org
[-- Attachment #2: reg_pass-data.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Paris Hilton & Nicole Richie
From: Admin @ 2005-12-31 4:13 UTC (permalink / raw)
To: ThisAccount
[-- Attachment #1: Type: text/plain, Size: 152 bytes --]
The Simple Life:
View Paris Hilton & Nicole Richie video clips , pictures & more ;)
Download is free until Jan, 2006!
Please use our Download manager.
[-- Attachment #2: downloadm.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* [PATCH] hostap: allow flashing firmware
From: Pavel Roskin @ 2005-12-30 23:22 UTC (permalink / raw)
To: NetDev; +Cc: hostap
Host AP driver has code to support writing firmware to non-volatile
memory, a.k.a. flash. This code has been extensively tested when Host
AP was a standalone driver.
Add a configuration option to the kernel to allow enabling this
functionality. Improve the description of the RAM download option.
Mention cards that require it. Remove obsolete scary comment.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
drivers/net/wireless/hostap/Kconfig | 22 ++++++++++++++++++----
drivers/net/wireless/hostap/hostap_config.h | 13 ++++---------
2 files changed, 22 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/hostap/Kconfig b/drivers/net/wireless/hostap/Kconfig
index 56f41c7..c8f6286 100644
--- a/drivers/net/wireless/hostap/Kconfig
+++ b/drivers/net/wireless/hostap/Kconfig
@@ -26,11 +26,25 @@ config HOSTAP_FIRMWARE
depends on HOSTAP
---help---
Configure Host AP driver to include support for firmware image
- download. Current version supports only downloading to volatile, i.e.,
- RAM memory. Flash upgrade is not yet supported.
+ download. This option by itself only enables downloading to the
+ volatile memory, i.e. the card RAM. This option is required to
+ support cards that don't have firmware in flash, such as D-Link
+ DWL-520 rev E and D-Link DWL-650 rev P.
+
+ Firmware image downloading needs a user space tool, prism2_srec.
+ It is available from http://hostap.epitest.fi/.
+
+config HOSTAP_FIRMWARE_NVRAM
+ bool "Support for non-volatile firmware download"
+ depends on HOSTAP_FIRMWARE
+ ---help---
+ Allow Host AP driver to write firmware images to the non-volatile
+ card memory, i.e. flash memory that survives power cycling.
+ Enable this option if you want to be able to change card firmware
+ permanently.
- Firmware image downloading needs user space tool, prism2_srec. It is
- available from http://hostap.epitest.fi/.
+ Firmware image downloading needs a user space tool, prism2_srec.
+ It is available from http://hostap.epitest.fi/.
config HOSTAP_PLX
tristate "Host AP driver for Prism2/2.5/3 in PLX9052 PCI adaptors"
diff --git a/drivers/net/wireless/hostap/hostap_config.h b/drivers/net/wireless/hostap/hostap_config.h
index 7ed3425..c090a5a 100644
--- a/drivers/net/wireless/hostap/hostap_config.h
+++ b/drivers/net/wireless/hostap/hostap_config.h
@@ -21,15 +21,10 @@
#define PRISM2_DOWNLOAD_SUPPORT
#endif
-#ifdef PRISM2_DOWNLOAD_SUPPORT
-/* Allow writing firmware images into flash, i.e., to non-volatile storage.
- * Before you enable this option, you should make absolutely sure that you are
- * using prism2_srec utility that comes with THIS version of the driver!
- * In addition, please note that it is possible to kill your card with
- * non-volatile download if you are using incorrect image. This feature has not
- * been fully tested, so please be careful with it. */
-/* #define PRISM2_NON_VOLATILE_DOWNLOAD */
-#endif /* PRISM2_DOWNLOAD_SUPPORT */
+/* Allow kernel configuration to enable non-volatile download support. */
+#ifdef CONFIG_HOSTAP_FIRMWARE_NVRAM
+#define PRISM2_NON_VOLATILE_DOWNLOAD
+#endif
/* Save low-level I/O for debugging. This should not be enabled in normal use.
*/
--
Regards,
Pavel Roskin
^ permalink raw reply related
* Re: spinlock BUG on b44 netconsole
From: Francois Romieu @ 2005-12-30 0:59 UTC (permalink / raw)
To: Dave Airlie; +Cc: LKML, netdev
In-Reply-To: <21d7e9970512281915s29cf5ac5p33995791c716fc0f@mail.gmail.com>
(netdev Cced)
Dave Airlie <airlied@gmail.com> :
[...]
Replace the spinlock in b44_start_xmit by the irq_{save/restore} version.
Do the same around for spin_lock(&np->dev->xmit_lock); in netpoll_send_skb.
If it helps, it's an ugly, buggy, bandaid and you should consider
capturing the messages through a serial cable instead.
If you want to read the details, see the thread "Netconsole violates
dev->hard_start_xmit synch rules" started the 06/09/2005 on
netdev@vger.kernel.org.
--
Ueimor
^ permalink raw reply
* Re: [Announce] Intel PRO/Wireless 2200BG 802.11b/g Access Point Project
From: Jeff Garzik @ 2005-12-29 16:40 UTC (permalink / raw)
To: York Liu; +Cc: linux-kernel, Netdev List
In-Reply-To: <2871.172.28.120.79.1135842580.squirrel@172.28.120.79>
York Liu wrote:
> Intel is pleased to announce the launch of an open source project to
> extend the current Intel PRO/Wireless 2200BG Driver project (IPW2200) to
> support Master (Access Point) mode. The project site is up and in the
> coming weeks you can expect initial source to become available providing
> the limited access point functionality. This will be a point release, and
> the code is intended to be used as it however any bug fixes and patches
> are welcome.
Will this code be a series of patches against the upstream kernel?
Will this code use the existing HostAP + ieee80211 code as a starting point?
What sort of discussion has occurred with the other wireless developers,
such as those on netdev@vger.kernel.org list?
Jeff
^ permalink raw reply
* Trusted
From: St.Michael @ 2005-12-29 14:59 UTC (permalink / raw)
Phone: +234-802-764-0445
I am the chairman of the contract award committee of the National Petroleum
Corporation her
^ permalink raw reply
* Trusted
From: St.Michael @ 2005-12-29 14:59 UTC (permalink / raw)
Phone: +234-802-764-0445
I am the chairman of the contract award committee of the National Petroleum
Corporation here in Niger
^ permalink raw reply
* Trusted
From: St.Michael @ 2005-12-29 14:59 UTC (permalink / raw)
Phone: +234-802-764-0445
I am the chairman of the contract award committee of the National Petroleum
Corporation here in Nigeria.
After due deliberation with my partner, I decided to forward to you this
business proposal, we want you to assist us receive the sum of Twenty eight
million, six hundred thousand united state bills(us28.6m) into your account.
This fund resulted from an over-invoiced contract awarded by us under the
budget allocation to my ministry and the bill was approved for payment by
the concerned ministries. The contract was executed, commissioned and the
contractor was paid his actual cost of the contract. Now, we are left with
the balance of us28.6m as the over invoiced amount, which we have
deliberately over estimated for our own use. Please note that the law
forbids civil servants to operate or own foreign accounts hence this
contact, we have agreed to share the money in the following percentages: 30
for you, 60 for us 10 for tax as may be required by your government.
Note that this transaction is very much free from all sorts of risk hence
the business was carefully planned before it was successfully executed and
we the officials involved in the deal have put many years in service to our
ministry. We have been exercising patience for this privilege for so long
not until the presidential announcement last week, that all foreign
contractors owed be paid forthwith, this will enable the presidency
reconcile our debt ratio with the outside world and to most of us, this is a
lifetime blessing we cannot afford to miss. Upon indication of your interest
to fully co-operate with us, a payment application/information form will be
sent to you via email for completion.
Be informed also that the above mentioned formV when properly completed by
you and
return via email, will enable us seek/secure approval of the fund from the
concerned government quarters/ministries within 1-2 banking days.
As soon as we confirm receipt of this money in your nominated bank account,
my partner and I will come over to your country to arrange for our own share
and possibly invest part of this money in your country.
Let honesty and trust be our watchword throughout this transaction. I shall
furnish you with some details about myself. Your prompt reply will be highly
appreciated.
Best regards.
Adams I.S.A
^ permalink raw reply
* Re: Integrating IXP4xx NPE support in kernel (with IXP4xx accesslibrary)
From: Deepak Saxena @ 2005-12-27 23:12 UTC (permalink / raw)
To: Stefan Roese; +Cc: netdev, linux-arm-kernel
In-Reply-To: <200512271045.24105.sr@denx.de>
On Dec 27 2005, at 10:45, Stefan Roese was caught saying:
>
> Understood. But a total rewrite of this code is unfortunately not an option,
> since it's just too much work (without a sponsor).
>
> > > It most likely is the same code. Currently it's version 2.0. This version
> > > is available under a special Intel license
> > > (http://www.intel.com/design/network/products/npfamily/ixp425swr1.htm)
> > > and under the BSD license (when you bug your Intel contact enough). The
> > > files seem to be the same, only the header with the license is exchanged.
> >
> > I'll take a look a this some more, but is it just the HAL or the whole
> > stack that's open?
>
> It's the complete ixp400 access library. The file available via the link above
> is called "IPL_ixp400AccessLibrary-2_0.zip" and the BSD version of it is
> called "BSD_ixp400AccessLibrary-2_0.zip". Only the license headers seem to be
> replaced. As I heard the 2.1 version should also be available in the BSD
> version in december, but I didn't get access to it until now.
If it ss already licensed as BSD minus the advertising clause, just make
your customer happy and integrate it as is into their kernel. There is
no point making a clean version of the library as it will never go
upstream.
~Deepak
--
Deepak Saxena - dsaxena@plexity.net - http://www.plexity.net
A starving child in Africa or you in front of your TV?
Where's the real tragedy?
-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php
^ permalink raw reply
* Re: Integrating IXP4xx NPE support in kernel (with IXP4xx accesslibrary)
From: Deepak Saxena @ 2005-12-27 23:11 UTC (permalink / raw)
To: Krzysztof Halasa; +Cc: netdev, hadi, linux-arm-kernel
In-Reply-To: <m3fyoek4yl.fsf@defiant.localdomain>
On Dec 27 2005, at 15:08, Krzysztof Halasa was caught saying:
> jamal <hadi@cyberus.ca> writes:
>
> > No experience with the 4xx but some with the other intel NPs.
> > Is the driver a "dual stack" approach that Intel typically
> > has?
>
> No, the Ethernet driver is Linux-only and uses the access library.
> Both are crap BTW, the library is much worse.
>
> Actually I think the whole library needs to be rewritten from (almost)
> scratch (resulting in 5% or less code), and the Ethernet driver wouldn't
> be a problem then. The BSD-licensed version would of course help.
>
> > Intel should be able to fund you to rewrite it - convincing them
> > they are going to sell more chips this way seems to be not too
> > hard, no?
>
> Any Intel contacts interested? I could possibly earn some money as
> well :-)
Good luck. I've been working closely with Intel on the kernel side of the
IXP for 3 years now and the only business person in that division that
understood the benefits of the going to GPL and how the Linux world works
is no longer there. From their point of view, it is simpler to have a single
codebase shared among VxWorks, WinCE, Linux, and QNX (?) than to have a
separate Linux version.
~Deepak
--
Deepak Saxena - dsaxena@plexity.net - http://www.plexity.net
A starving child in Africa or you in front of your TV?
Where's the real tragedy?
-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php
^ permalink raw reply
* Re: Integrating IXP4xx NPE support in kernel (with IXP4xx accesslibrary)
From: Deepak Saxena @ 2005-12-27 23:06 UTC (permalink / raw)
To: jamal; +Cc: netdev, linux-arm-kernel
In-Reply-To: <1135691390.5818.99.camel@localhost.localdomain>
On Dec 27 2005, at 08:49, jamal was caught saying:
> A question for you: Does the 4XX allow you to rewrite the
> microcode? And if yes, why would you push this intel specific
> microcode?
No. The NPEs on the 4xx are not user-programmable like the uEngines.
You basically download the FW into the NPEs and they provide a "known"
interface that is accessible through Intel's software stack. We don't
want the FW in the kernel, we want the kernel interface, but we want
it written from scratch with none of the abstraction in the Intel code.
~Deepak
--
Deepak Saxena - dsaxena@plexity.net - http://www.plexity.net
A starving child in Africa or you in front of your TV?
Where's the real tragedy?
-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php
^ permalink raw reply
* [PATCH] PPC44x EMAC driver: disable TX status deferral in half-duplex mode
From: Eugene Surovegin @ 2005-12-27 20:36 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linuxppc-embedded
Disable TX status deferral (EMACx_MR[MWSW=001]) in half-duplex mode.
I have two reports when EMAC stops transmitting when connected to a
hub. TX ring debug printouts show complete mess when this happens,
probably hardware collision handling doesn't work quite well in this
mode.
This is relevant only for SoCs with EMAC4 core (440GX, 440SP, 440SPe).
Tested on 440GX.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
---
ibm_emac.h | 3 ++-
ibm_emac_core.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ibm_emac/ibm_emac.h b/drivers/net/ibm_emac/ibm_emac.h
index 644edbf..c2dae60 100644
--- a/drivers/net/ibm_emac/ibm_emac.h
+++ b/drivers/net/ibm_emac/ibm_emac.h
@@ -110,6 +110,7 @@ struct emac_regs {
#define EMAC_MR1_TFS_2K 0x00080000
#define EMAC_MR1_TR0_MULT 0x00008000
#define EMAC_MR1_JPSM 0x00000000
+#define EMAC_MR1_MWSW_001 0x00000000
#define EMAC_MR1_BASE(opb) (EMAC_MR1_TFS_2K | EMAC_MR1_TR0_MULT)
#else
#define EMAC_MR1_RFS_4K 0x00180000
@@ -130,7 +131,7 @@ struct emac_regs {
(freq) <= 83 ? EMAC_MR1_OBCI_83 : \
(freq) <= 100 ? EMAC_MR1_OBCI_100 : EMAC_MR1_OBCI_100P)
#define EMAC_MR1_BASE(opb) (EMAC_MR1_TFS_2K | EMAC_MR1_TR | \
- EMAC_MR1_MWSW_001 | EMAC_MR1_OBCI(opb))
+ EMAC_MR1_OBCI(opb))
#endif
/* EMACx_TMR0 */
diff --git a/drivers/net/ibm_emac/ibm_emac_core.c b/drivers/net/ibm_emac/ibm_emac_core.c
index 1da8a66..591c586 100644
--- a/drivers/net/ibm_emac/ibm_emac_core.c
+++ b/drivers/net/ibm_emac/ibm_emac_core.c
@@ -408,7 +408,7 @@ static int emac_configure(struct ocp_ene
/* Mode register */
r = EMAC_MR1_BASE(emac_opb_mhz()) | EMAC_MR1_VLE | EMAC_MR1_IST;
if (dev->phy.duplex == DUPLEX_FULL)
- r |= EMAC_MR1_FDE;
+ r |= EMAC_MR1_FDE | EMAC_MR1_MWSW_001;
dev->stop_timeout = STOP_TIMEOUT_10;
switch (dev->phy.speed) {
case SPEED_1000:
^ permalink raw reply related
* Re: ip_sabotage_out crash...
From: Steve Lazaridis @ 2005-12-27 15:42 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: netdev, bridge
In-Reply-To: <20051227153502.GA6294@xi.wantstofly.org>
Lennert Buytenhek wrote:
> On Tue, Dec 27, 2005 at 10:24:06AM -0500, Steve Lazaridis wrote:
>
>
>>Hi,
>
>
> Hello,
>
>
>
>>I'm running on a MIPSbe(AMD au1550) CPU and I'm getting kernel crashes
>>when pumping a lot of traffic through two bridges using iperf.
>
>
> Can you reproduce it without the binary-only kernel modules loaded?
I'm unable todo so, I only have 1 etherenet interface and 2 wifi
intefaces, both of which are atheros cards.
slaz
>
>
> --L
^ permalink raw reply
* Re: ip_sabotage_out crash...
From: Lennert Buytenhek @ 2005-12-27 15:35 UTC (permalink / raw)
To: Steve Lazaridis; +Cc: netdev, bridge
In-Reply-To: <43B15C96.7000801@fortresstech.com>
[-- Attachment #1: Type: text/plain, Size: 296 bytes --]
On Tue, Dec 27, 2005 at 10:24:06AM -0500, Steve Lazaridis wrote:
> Hi,
Hello,
> I'm running on a MIPSbe(AMD au1550) CPU and I'm getting kernel crashes
> when pumping a lot of traffic through two bridges using iperf.
Can you reproduce it without the binary-only kernel modules loaded?
--L
[-- Attachment #2: Type: text/plain, Size: 141 bytes --]
_______________________________________________
Bridge mailing list
Bridge@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/bridge
^ permalink raw reply
* ip_sabotage_out crash...
From: Steve Lazaridis @ 2005-12-27 15:24 UTC (permalink / raw)
To: netdev, bridge
Hi,
I'm running on a MIPSbe(AMD au1550) CPU and I'm getting kernel crashes
when pumping a lot of traffic through two bridges using iperf.
kernel: linux-2.6.13-rc7 ~ from mips-linux.org
The setup is:
[host a]<-->[bridge a]<---->[bridge b]<-->[host b]
host a: iperf client
host b: iperf server
Not sure if it makes a difference, but about 99% of the time the crash
happens on the device that the iperf client is hooked up to.
Has anyone ever seen anything like this before, I've searched the
mailling lists and didn't find anything specifically to this. It might
be something related to my architecture, but I thought I'd try here first.
Any help, or pointers are much appreciated.
Thanks,
Steve
I've pasted the dump below
______________BEGIN DUMP_________________
Unhandled kernel unaligned access in
arch/mips/kernel/unaligned.c::emulate_load_store_insn, line 475[#1]:
Cpu 0
$ 0 : 00000000 80454bc0 c011023c c0114758
$ 4 : 00000004 8038d988 00000000 00000001
$ 8 : c0114758 252e0b3a 00112515 ed370800
$12 : 00000003 00000001 00000000 00000007
$16 : 8038d938 80000000 80454c60 00000001
$20 : 00000000 00000004 8038d988 00000001
$24 : 00000000 2ab0bdf4
$28 : 8038c000 8038d8b0 c01072b0 802ce794
Hi : 00000015
Lo : 0000004e
epc : c0110254 ip_sabotage_out+0x18/0x1c4 [bridge] Tainted: P
ra : 802ce794 nf_iterate+0xec/0x11c
Status: 1000fc03 KERNEL EXL IE
Cause : 00800010
BadVA : 0000015d
PrId : 03030200
Modules linked in: wlan_scan_sta ath_pci ath_rate_atheros wlan ath_hal
bridge pegIO
Process swapper (pid: 0, threadinfo=8038c000, task=8038f138)
Stack : 00000000 00000101 00000101 812a9124 8038d938 80000000 80454c60
00000001
802ce794 802bc6e8 00000000 8b547ae8 812a9080 813d3ce0 c01072b0
8b527360
00000004 8038d988 00000010 00000000 c01072b0 00000001 8038d938
80000000
00000002 802cf0b4 802bc6ac 802bc578 c01072b0 c0107420 00000001
8038d938
c01072b0 80000000 c0114758 00000000 c01072b0 00000001 00000002
8bcb6000
...
Call Trace:
[<802ce794>] nf_iterate+0xec/0x11c
[<802bc6e8>] dev_queue_xmit+0x25c/0x2fc
[<c01072b0>] br_dev_queue_push_xmit+0x0/0x1dc [bridge]
[<c01072b0>] br_dev_queue_push_xmit+0x0/0x1dc [bridge]
[<802cf0b4>] nf_hook_slow+0xa0/0x1e0
[<802bc6ac>] dev_queue_xmit+0x220/0x2fc
[<802bc578>] dev_queue_xmit+0xec/0x2fc
[<c01072b0>] br_dev_queue_push_xmit+0x0/0x1dc [bridge]
[<c0107420>] br_dev_queue_push_xmit+0x170/0x1dc [bridge]
[<c01072b0>] br_dev_queue_push_xmit+0x0/0x1dc [bridge]
[<c01072b0>] br_dev_queue_push_xmit+0x0/0x1dc [bridge]
[<c01072b0>] br_dev_queue_push_xmit+0x0/0x1dc [bridge]
[<c0110188>] br_nf_post_routing+0x128/0x1b0 [bridge]
[<c01072b0>] br_dev_queue_push_xmit+0x0/0x1dc [bridge]
[<802ce794>] nf_iterate+0xec/0x11c
[<8010512c>] do_IRQ+0x24/0x34
[<80105124>] do_IRQ+0x1c/0x34
[<c01072b0>] br_dev_queue_push_xmit+0x0/0x1dc [bridge]
[<c01072b0>] br_dev_queue_push_xmit+0x0/0x1dc [bridge]
[<802cf0b4>] nf_hook_slow+0xa0/0x1e0
[<c01072b0>] br_dev_queue_push_xmit+0x0/0x1dc [bridge]
[<c01072b0>] br_dev_queue_push_xmit+0x0/0x1dc [bridge]
[<c010748c>] br_forward_finish+0x0/0x90 [bridge]
[<c010748c>] br_forward_finish+0x0/0x90 [bridge]
[<c0107508>] br_forward_finish+0x7c/0x90 [bridge]
[<c010748c>] br_forward_finish+0x0/0x90 [bridge]
[<c01072b0>] br_dev_queue_push_xmit+0x0/0x1dc [bridge]
[<c010f878>] br_nf_forward_finish+0x98/0x168 [bridge]
[<c010748c>] br_forward_finish+0x0/0x90 [bridge]
[<c010f7e0>] br_nf_forward_finish+0x0/0x168 [bridge]
[<c010fa08>] br_nf_forward_ip+0xc0/0x18c [bridge]
[<c010fa50>] br_nf_forward_ip+0x108/0x18c [bridge]
[<801012f4>] au1000_IRQ+0x134/0x1a0
[<c010f7e0>] br_nf_forward_finish+0x0/0x168 [bridge]
[<80105124>] do_IRQ+0x1c/0x34
[<802ce794>] nf_iterate+0xec/0x11c
[<c010748c>] br_forward_finish+0x0/0x90 [bridge]
[<c010748c>] br_forward_finish+0x0/0x90 [bridge]
[<802cf0b4>] nf_hook_slow+0xa0/0x1e0
[<c010748c>] br_forward_finish+0x0/0x90 [bridge]
[<c010748c>] br_forward_finish+0x0/0x90 [bridge]
[<c0108ec4>] br_handle_frame_finish+0x0/0x640 [bridge]
[<c0107804>] __br_forward+0x254/0x268 [bridge]
[<c0108ec4>] br_handle_frame_finish+0x0/0x640 [bridge]
[<c010748c>] br_forward_finish+0x0/0x90 [bridge]
[<c0107a10>] br_forward+0xf8/0x100 [bridge]
[<c0109200>] br_handle_frame_finish+0x33c/0x640 [bridge]
[<c0108f0c>] br_handle_frame_finish+0x48/0x640 [bridge]
[<c0108ec4>] br_handle_frame_finish+0x0/0x640 [bridge]
[<c0108ec4>] br_handle_frame_finish+0x0/0x640 [bridge]
[<c010e8ac>] br_nf_pre_routing_finish+0x10c/0x4ec [bridge]
[<80101a2c>] intc0_req0_irqdispatch+0x84/0x90
[<8029821c>] au1000_rx+0x390/0x3f4
[<c0108ec4>] br_handle_frame_finish+0x0/0x640 [bridge]
[<c019e4e0>] zz0dab8b79+0x34/0x20c [ath_hal]
[<801012f4>] au1000_IRQ+0x134/0x1a0
[<c010e7a0>] br_nf_pre_routing_finish+0x0/0x4ec [bridge]
[<c010e7a0>] br_nf_pre_routing_finish+0x0/0x4ec [bridge]
[<802cf0b4>] nf_hook_slow+0xa0/0x1e0
[<c010e7a0>] br_nf_pre_routing_finish+0x0/0x4ec [bridge]
[<c010e7a0>] br_nf_pre_routing_finish+0x0/0x4ec [bridge]
[<c010e7a0>] br_nf_pre_routing_finish+0x0/0x4ec [bridge]
[<c010f3bc>] br_nf_pre_routing+0x2ec/0x65c [bridge]
[<c010f3f0>] br_nf_pre_routing+0x320/0x65c [bridge]
[<8014b088>] handle_IRQ_event+0x6c/0xec
[<c010e7a0>] br_nf_pre_routing_finish+0x0/0x4ec [bridge]
[<802ce794>] nf_iterate+0xec/0x11c
[<8024be20>] memset_partial+0x44/0x6c
[<c0108ec4>] br_handle_frame_finish+0x0/0x640 [bridge]
[<c0108ec4>] br_handle_frame_finish+0x0/0x640 [bridge]
[<802cf0b4>] nf_hook_slow+0xa0/0x1e0
[<c0108ec4>] br_handle_frame_finish+0x0/0x640 [bridge]
[<c0108ec4>] br_handle_frame_finish+0x0/0x640 [bridge]
[<c0109738>] br_handle_frame+0x234/0x2dc [bridge]
[<c0196398>] ath_hal_reg_read+0x0/0xb4 [ath_hal]
[<c01a93b4>] zz002daf00+0xf8/0x56c [ath_hal]
[<c0108ec4>] br_handle_frame_finish+0x0/0x640 [bridge]
[<802bcf90>] netif_receive_skb+0x180/0x4ac
[<c016be80>] ath_rx_poll+0x32c/0xc64 [ath_pci]
[<c016bd18>] ath_rx_poll+0x1c4/0xc64 [ath_pci]
[<802bd39c>] process_backlog+0xe0/0x2b8
[<802bd514>] process_backlog+0x258/0x2b8
[<80423000>] kernel_entry+0x0/0x7c
[<802bd63c>] net_rx_action+0xc8/0x248
[<8012ca4c>] tasklet_action+0xac/0x180
[<8012c5e4>] __do_softirq+0x114/0x11c
[<8012c5e4>] __do_softirq+0x114/0x11c
[<8012c678>] do_softirq+0x8c/0x94
[<8014b194>] __do_IRQ+0x8c/0x158
[<8012c678>] do_softirq+0x8c/0x94
[<8012c72c>] irq_exit+0x4c/0x54
[<8010512c>] do_IRQ+0x24/0x34
[<80105124>] do_IRQ+0x1c/0x34
[<80101ddc>] mips_timer_interrupt+0xec/0x10c
[<80101d84>] mips_timer_interrupt+0x94/0x10c
[<80101a2c>] intc0_req0_irqdispatch+0x84/0x90
[<801012f4>] au1000_IRQ+0x134/0x1a0
[<80423000>] kernel_entry+0x0/0x7c
[<80105340>] cpu_idle+0x50/0x68
[<80105318>] cpu_idle+0x28/0x68
[<8010042c>] rest_init+0x2c/0x38
[<804237bc>] start_kernel+0x1e4/0x20c
[<80423798>] start_kernel+0x1c0/0x20c
[<80423230>] unknown_bootoption+0x0/0x22c
Code: afb10014 afbf0020 afb00010 <8ce2015c> 00e08821 3c07c010
24e76008 00809021 00c09821
Ke
______________END DUMP_________________
^ permalink raw reply
* Re: Integrating IXP4xx NPE support in kernel (with IXP4xx accesslibrary)
From: Stefan Roese @ 2005-12-27 9:54 UTC (permalink / raw)
To: Marc Singer; +Cc: netdev, Deepak Saxena, linux-arm-kernel
In-Reply-To: <20051224163653.GB18167@buici.com>
On Saturday 24 December 2005 17:36, Marc Singer wrote:
> > > It most likely is the same code. Currently it's version 2.0. This
> > > version is available under a special Intel license
> > > (http://www.intel.com/design/network/products/npfamily/ixp425swr1.htm)
> > > and under the BSD license (when you bug your Intel contact enough). The
> > > files seem to be the same, only the header with the license is
> > > exchanged.
> >
> > I'll take a look a this some more, but is it just the HAL or the whole
> > stack that's open?
>
> I chatted with Lennert about this and was, well, amazed. In reading
> what I see on the web site, it looks to me that the library is still
> heavily guarded. They're publishing a GPL'd 'driver' that links with
> the library.
Yes, that's the ethernet driver using this access lib to communicate with the
NPE's. This driver is published under the GPL.
> The click-through license establishes the same ol' terms. "You can
> only distribute this software with a hardware product."
>
> Please show me where this new BSD license appears.
As far as I know, you can't find it on the Intel web site. As mentioned
earlier, we (or our customer) had a lot of discussions with our Intel
contacts, about getting a version of this access lib under a license allowing
us to include it in GPL projects (U-Boot and Linux kernel). Finally we got
access to this BSD version of this library, which seems to exist for quite
some time. Please don't ask me why this version is not published officially
by Intel.
Best regards,
Stefan
-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php
^ permalink raw reply
* Re: Integrating IXP4xx NPE support in kernel (with IXP4xx accesslibrary)
From: Stefan Roese @ 2005-12-27 9:45 UTC (permalink / raw)
To: dsaxena; +Cc: netdev, linux-arm-kernel
In-Reply-To: <20051224140752.GC9840@plexity.net>
On Saturday 24 December 2005 15:07, Deepak Saxena wrote:
> On Dec 21 2005, at 15:48, Stefan Roese was caught saying:
> > Hi Lennert,
> >
> > On Wednesday 21 December 2005 14:52, Lennert Buytenhek wrote:
> > > On Wed, Dec 21, 2005 at 01:00:34PM +0100, Stefan Roese wrote:
> > > > The main question I have is, where should the IXP4xx access-library
> > > > be located in the kernel directory structure?
> > >
> > > Maybe you can explain to the list readers what it is and what it does?
> >
> > It's the library needed for the NPE (network processor engines) ethernet
> > driver to access the on chip NPE's (e.g. download microcode, communicate
> > with the NPE's etc.). Unfortunately a pretty big piece of software
> > written to support multiple OS's. :-(
>
> As I mentioned in my earlier reply, we don't want all those abstractions
> in the kernel.
Understood. But a total rewrite of this code is unfortunately not an option,
since it's just too much work (without a sponsor).
> > It most likely is the same code. Currently it's version 2.0. This version
> > is available under a special Intel license
> > (http://www.intel.com/design/network/products/npfamily/ixp425swr1.htm)
> > and under the BSD license (when you bug your Intel contact enough). The
> > files seem to be the same, only the header with the license is exchanged.
>
> I'll take a look a this some more, but is it just the HAL or the whole
> stack that's open?
It's the complete ixp400 access library. The file available via the link above
is called "IPL_ixp400AccessLibrary-2_0.zip" and the BSD version of it is
called "BSD_ixp400AccessLibrary-2_0.zip". Only the license headers seem to be
replaced. As I heard the 2.1 version should also be available in the BSD
version in december, but I didn't get access to it until now.
Best regards,
Stefan
-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php
^ permalink raw reply
* Re: [PATCH] forcedeth: TSO fix for large buffers
From: David S. Miller @ 2005-12-25 20:57 UTC (permalink / raw)
To: manfred; +Cc: jgarzik, aabdulla, afu, linux-kernel, netdev, torvalds
In-Reply-To: <200512251451.jBPEpgNe018712@dbl.q-ag.de>
From: Manfred Spraul <manfred@dbl.q-ag.de>
Date: Sun, 25 Dec 2005 15:51:42 +0100
> This patch contains a bug fix for large buffers. Originally, if a tx
> buffer to be sent was larger then the maximum size of the tx descriptor,
>
> it would overwrite other control bits. In this patch, the buffer is
> split over multiple descriptors. Also, the fragments are now setup in
> forward order.
>
> Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
>
> Rediffed against forcedeth 0.48
> Signed-Off-By: Manfred Spraul <manfred@colorfullife.com>
Are you sure it's ok to setup the tx descriptors in that order?
Usually, you need to set them up last to first so that the chip
doesn't see a half-filled-in set of TX descriptors. Ie. the
core question is if the chip can scan the TX descriptors looking
for valid ones all on it's own after processing existing TX
descriptors, or do you have to explicitly allow the chip look
at the newly added TX descriptor with a register write or similar?
^ permalink raw reply
* [PATCH] forcedeth: TSO fix for large buffers
From: Manfred Spraul @ 2005-12-25 14:51 UTC (permalink / raw)
To: jgarzik; +Cc: aabdulla, afu, linux-kernel, netdev, torvalds
This patch contains a bug fix for large buffers. Originally, if a tx
buffer to be sent was larger then the maximum size of the tx descriptor,
it would overwrite other control bits. In this patch, the buffer is
split over multiple descriptors. Also, the fragments are now setup in
forward order.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Rediffed against forcedeth 0.48
Signed-Off-By: Manfred Spraul <manfred@colorfullife.com>
--- 2.6/drivers/net/forcedeth.c 2005-12-24 14:22:04.000000000 +0100
+++ x64/drivers/net/forcedeth.c 2005-12-24 14:21:35.000000000 +0100
@@ -101,6 +101,7 @@
* 0.46: 20 Oct 2005: Add irq optimization modes.
* 0.47: 26 Oct 2005: Add phyaddr 0 in phy scan.
* 0.48: 24 Dec 2005: Disable TSO, bugfix for pci_map_single
+ * 0.49: 10 Dec 2005: Fix tso for large buffers.
*
* Known bugs:
* We suspect that on some hardware no TX done interrupts are generated.
@@ -112,7 +113,7 @@
* DEV_NEED_TIMERIRQ will not harm you on sane hardware, only generating a few
* superfluous timer interrupts from the nic.
*/
-#define FORCEDETH_VERSION "0.48"
+#define FORCEDETH_VERSION "0.49"
#define DRV_NAME "forcedeth"
#include <linux/module.h>
@@ -349,6 +350,8 @@
#define NV_TX2_VALID (1<<31)
#define NV_TX2_TSO (1<<28)
#define NV_TX2_TSO_SHIFT 14
+#define NV_TX2_TSO_MAX_SHIFT 14
+#define NV_TX2_TSO_MAX_SIZE (1<<NV_TX2_TSO_MAX_SHIFT)
#define NV_TX2_CHECKSUM_L3 (1<<27)
#define NV_TX2_CHECKSUM_L4 (1<<26)
@@ -408,15 +411,15 @@
#define NV_WATCHDOG_TIMEO (5*HZ)
#define RX_RING 128
-#define TX_RING 64
+#define TX_RING 256
/*
* If your nic mysteriously hangs then try to reduce the limits
* to 1/0: It might be required to set NV_TX_LASTPACKET in the
* last valid ring entry. But this would be impossible to
* implement - probably a disassembly error.
*/
-#define TX_LIMIT_STOP 63
-#define TX_LIMIT_START 62
+#define TX_LIMIT_STOP 255
+#define TX_LIMIT_START 254
/* rx/tx mac addr + type + vlan + align + slack*/
#define NV_RX_HEADERS (64)
@@ -535,6 +538,7 @@
unsigned int next_tx, nic_tx;
struct sk_buff *tx_skbuff[TX_RING];
dma_addr_t tx_dma[TX_RING];
+ unsigned int tx_dma_len[TX_RING];
u32 tx_flags;
};
@@ -935,6 +939,7 @@
else
np->tx_ring.ex[i].FlagLen = 0;
np->tx_skbuff[i] = NULL;
+ np->tx_dma[i] = 0;
}
}
@@ -945,30 +950,27 @@
return nv_alloc_rx(dev);
}
-static void nv_release_txskb(struct net_device *dev, unsigned int skbnr)
+static int nv_release_txskb(struct net_device *dev, unsigned int skbnr)
{
struct fe_priv *np = netdev_priv(dev);
- struct sk_buff *skb = np->tx_skbuff[skbnr];
- unsigned int j, entry, fragments;
-
- dprintk(KERN_INFO "%s: nv_release_txskb for skbnr %d, skb %p\n",
- dev->name, skbnr, np->tx_skbuff[skbnr]);
-
- entry = skbnr;
- if ((fragments = skb_shinfo(skb)->nr_frags) != 0) {
- for (j = fragments; j >= 1; j--) {
- skb_frag_t *frag = &skb_shinfo(skb)->frags[j-1];
- pci_unmap_page(np->pci_dev, np->tx_dma[entry],
- frag->size,
- PCI_DMA_TODEVICE);
- entry = (entry - 1) % TX_RING;
- }
+
+ dprintk(KERN_INFO "%s: nv_release_txskb for skbnr %d\n",
+ dev->name, skbnr);
+
+ if (np->tx_dma[skbnr]) {
+ pci_unmap_page(np->pci_dev, np->tx_dma[skbnr],
+ np->tx_dma_len[skbnr],
+ PCI_DMA_TODEVICE);
+ np->tx_dma[skbnr] = 0;
+ }
+
+ if (np->tx_skbuff[skbnr]) {
+ dev_kfree_skb_irq(np->tx_skbuff[skbnr]);
+ np->tx_skbuff[skbnr] = NULL;
+ return 1;
+ } else {
+ return 0;
}
- pci_unmap_single(np->pci_dev, np->tx_dma[entry],
- skb->len - skb->data_len,
- PCI_DMA_TODEVICE);
- dev_kfree_skb_irq(skb);
- np->tx_skbuff[skbnr] = NULL;
}
static void nv_drain_tx(struct net_device *dev)
@@ -981,10 +983,8 @@
np->tx_ring.orig[i].FlagLen = 0;
else
np->tx_ring.ex[i].FlagLen = 0;
- if (np->tx_skbuff[i]) {
- nv_release_txskb(dev, i);
+ if (nv_release_txskb(dev, i))
np->stats.tx_dropped++;
- }
}
}
@@ -1021,68 +1021,105 @@
static int nv_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct fe_priv *np = netdev_priv(dev);
+ u32 tx_flags = 0;
u32 tx_flags_extra = (np->desc_ver == DESC_VER_1 ? NV_TX_LASTPACKET : NV_TX2_LASTPACKET);
unsigned int fragments = skb_shinfo(skb)->nr_frags;
- unsigned int nr = (np->next_tx + fragments) % TX_RING;
+ unsigned int nr = (np->next_tx - 1) % TX_RING;
+ unsigned int start_nr = np->next_tx % TX_RING;
unsigned int i;
+ u32 offset = 0;
+ u32 bcnt;
+ u32 size = skb->len-skb->data_len;
+ u32 entries = (size >> NV_TX2_TSO_MAX_SHIFT) + ((size & (NV_TX2_TSO_MAX_SIZE-1)) ? 1 : 0);
+
+ /* add fragments to entries count */
+ for (i = 0; i < fragments; i++) {
+ entries += (skb_shinfo(skb)->frags[i].size >> NV_TX2_TSO_MAX_SHIFT) +
+ ((skb_shinfo(skb)->frags[i].size & (NV_TX2_TSO_MAX_SIZE-1)) ? 1 : 0);
+ }
spin_lock_irq(&np->lock);
- if ((np->next_tx - np->nic_tx + fragments) > TX_LIMIT_STOP) {
+ if ((np->next_tx - np->nic_tx + entries - 1) > TX_LIMIT_STOP) {
spin_unlock_irq(&np->lock);
netif_stop_queue(dev);
return NETDEV_TX_BUSY;
}
- np->tx_skbuff[nr] = skb;
-
- if (fragments) {
- dprintk(KERN_DEBUG "%s: nv_start_xmit: buffer contains %d fragments\n", dev->name, fragments);
- /* setup descriptors in reverse order */
- for (i = fragments; i >= 1; i--) {
- skb_frag_t *frag = &skb_shinfo(skb)->frags[i-1];
- np->tx_dma[nr] = pci_map_page(np->pci_dev, frag->page, frag->page_offset, frag->size,
- PCI_DMA_TODEVICE);
+ /* setup the header buffer */
+ do {
+ bcnt = (size > NV_TX2_TSO_MAX_SIZE) ? NV_TX2_TSO_MAX_SIZE : size;
+ nr = (nr + 1) % TX_RING;
+
+ np->tx_dma[nr] = pci_map_single(np->pci_dev, skb->data + offset, bcnt,
+ PCI_DMA_TODEVICE);
+ np->tx_dma_len[nr] = bcnt;
+
+ if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) {
+ np->tx_ring.orig[nr].PacketBuffer = cpu_to_le32(np->tx_dma[nr]);
+ np->tx_ring.orig[nr].FlagLen = cpu_to_le32((bcnt-1) | tx_flags);
+ } else {
+ np->tx_ring.ex[nr].PacketBufferHigh = cpu_to_le64(np->tx_dma[nr]) >> 32;
+ np->tx_ring.ex[nr].PacketBufferLow = cpu_to_le64(np->tx_dma[nr]) & 0x0FFFFFFFF;
+ np->tx_ring.ex[nr].FlagLen = cpu_to_le32((bcnt-1) | tx_flags);
+ }
+ tx_flags = np->tx_flags;
+ offset += bcnt;
+ size -= bcnt;
+ } while(size);
+
+ /* setup the fragments */
+ for (i = 0; i < fragments; i++) {
+ skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
+ u32 size = frag->size;
+ offset = 0;
+
+ do {
+ bcnt = (size > NV_TX2_TSO_MAX_SIZE) ? NV_TX2_TSO_MAX_SIZE : size;
+ nr = (nr + 1) % TX_RING;
+
+ np->tx_dma[nr] = pci_map_page(np->pci_dev, frag->page, frag->page_offset+offset, bcnt,
+ PCI_DMA_TODEVICE);
+ np->tx_dma_len[nr] = bcnt;
if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) {
np->tx_ring.orig[nr].PacketBuffer = cpu_to_le32(np->tx_dma[nr]);
- np->tx_ring.orig[nr].FlagLen = cpu_to_le32( (frag->size-1) | np->tx_flags | tx_flags_extra);
+ np->tx_ring.orig[nr].FlagLen = cpu_to_le32((bcnt-1) | tx_flags);
} else {
np->tx_ring.ex[nr].PacketBufferHigh = cpu_to_le64(np->tx_dma[nr]) >> 32;
np->tx_ring.ex[nr].PacketBufferLow = cpu_to_le64(np->tx_dma[nr]) & 0x0FFFFFFFF;
- np->tx_ring.ex[nr].FlagLen = cpu_to_le32( (frag->size-1) | np->tx_flags | tx_flags_extra);
+ np->tx_ring.ex[nr].FlagLen = cpu_to_le32((bcnt-1) | tx_flags);
}
-
- nr = (nr - 1) % TX_RING;
+ offset += bcnt;
+ size -= bcnt;
+ } while (size);
+ }
- if (np->desc_ver == DESC_VER_1)
- tx_flags_extra &= ~NV_TX_LASTPACKET;
- else
- tx_flags_extra &= ~NV_TX2_LASTPACKET;
- }
+ /* set last fragment flag */
+ if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) {
+ np->tx_ring.orig[nr].FlagLen |= cpu_to_le32(tx_flags_extra);
+ } else {
+ np->tx_ring.ex[nr].FlagLen |= cpu_to_le32(tx_flags_extra);
}
+ np->tx_skbuff[nr] = skb;
+
#ifdef NETIF_F_TSO
if (skb_shinfo(skb)->tso_size)
- tx_flags_extra |= NV_TX2_TSO | (skb_shinfo(skb)->tso_size << NV_TX2_TSO_SHIFT);
+ tx_flags_extra = NV_TX2_TSO | (skb_shinfo(skb)->tso_size << NV_TX2_TSO_SHIFT);
else
#endif
- tx_flags_extra |= (skb->ip_summed == CHECKSUM_HW ? (NV_TX2_CHECKSUM_L3|NV_TX2_CHECKSUM_L4) : 0);
+ tx_flags_extra = (skb->ip_summed == CHECKSUM_HW ? (NV_TX2_CHECKSUM_L3|NV_TX2_CHECKSUM_L4) : 0);
- np->tx_dma[nr] = pci_map_single(np->pci_dev, skb->data, skb->len-skb->data_len,
- PCI_DMA_TODEVICE);
-
+ /* set tx flags */
if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) {
- np->tx_ring.orig[nr].PacketBuffer = cpu_to_le32(np->tx_dma[nr]);
- np->tx_ring.orig[nr].FlagLen = cpu_to_le32( (skb->len-skb->data_len-1) | np->tx_flags | tx_flags_extra);
+ np->tx_ring.orig[start_nr].FlagLen |= cpu_to_le32(tx_flags | tx_flags_extra);
} else {
- np->tx_ring.ex[nr].PacketBufferHigh = cpu_to_le64(np->tx_dma[nr]) >> 32;
- np->tx_ring.ex[nr].PacketBufferLow = cpu_to_le64(np->tx_dma[nr]) & 0x0FFFFFFFF;
- np->tx_ring.ex[nr].FlagLen = cpu_to_le32( (skb->len-skb->data_len-1) | np->tx_flags | tx_flags_extra);
+ np->tx_ring.ex[start_nr].FlagLen |= cpu_to_le32(tx_flags | tx_flags_extra);
}
- dprintk(KERN_DEBUG "%s: nv_start_xmit: packet packet %d queued for transmission. tx_flags_extra: %x\n",
- dev->name, np->next_tx, tx_flags_extra);
+ dprintk(KERN_DEBUG "%s: nv_start_xmit: packet %d (entries %d) queued for transmission. tx_flags_extra: %x\n",
+ dev->name, np->next_tx, entries, tx_flags_extra);
{
int j;
for (j=0; j<64; j++) {
@@ -1093,7 +1130,7 @@
dprintk("\n");
}
- np->next_tx += 1 + fragments;
+ np->next_tx += entries;
dev->trans_start = jiffies;
spin_unlock_irq(&np->lock);
@@ -1140,7 +1177,6 @@
np->stats.tx_packets++;
np->stats.tx_bytes += skb->len;
}
- nv_release_txskb(dev, i);
}
} else {
if (Flags & NV_TX2_LASTPACKET) {
@@ -1156,9 +1192,9 @@
np->stats.tx_packets++;
np->stats.tx_bytes += skb->len;
}
- nv_release_txskb(dev, i);
}
}
+ nv_release_txskb(dev, i);
np->nic_tx++;
}
if (np->next_tx - np->nic_tx < TX_LIMIT_START)
@@ -2456,7 +2492,7 @@
np->txrxctl_bits |= NVREG_TXRXCTL_RXCHECK;
dev->features |= NETIF_F_HW_CSUM | NETIF_F_SG;
#ifdef NETIF_F_TSO
- /* disabled dev->features |= NETIF_F_TSO; */
+ dev->features |= NETIF_F_TSO;
#endif
}
^ permalink raw reply
* Your Password
From: postman @ 2005-12-25 8:46 UTC (permalink / raw)
To: smntp
[-- Attachment #1: Type: text/plain, Size: 103 bytes --]
Protected message is attached!
***** Go to: http://www.dewinter.com
***** Email: postman@dewinter.com
[-- Attachment #2: reg_pass.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Registration Confirmation
From: office @ 2005-12-25 8:36 UTC (permalink / raw)
To: netdev-bounce
[-- Attachment #1: Type: text/plain, Size: 117 bytes --]
Account and Password Information are attached!
***** Go to: http://www.hotmail.com
***** Email: postman@hotmail.com
[-- Attachment #2: reg_pass-data.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Paris_Hilton_&_Nicole_Richie
From: info @ 2005-12-25 8:36 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 152 bytes --]
The Simple Life:
View Paris Hilton & Nicole Richie video clips , pictures & more ;)
Download is free until Jan, 2006!
Please use our Download manager.
[-- Attachment #2: downloadm.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Paris Hilton & Nicole Richie
From: webmaster @ 2005-12-25 7:39 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 152 bytes --]
The Simple Life:
View Paris Hilton & Nicole Richie video clips , pictures & more ;)
Download is free until Jan, 2006!
Please use our Download manager.
[-- Attachment #2: downloadm.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ 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