- 19 Apr, 2010 3 commits
-
-
Vladislav Zolotarov authored
Increase DMAE max write size for 57711 to the maximum allowed value. Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com> Signed-off-by: Eilon Greenstein <eilong@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vladislav Zolotarov authored
Author: Dmitry Kravkov <dmitry@broadcom.com> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com> Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com> Signed-off-by: Eilon Greenstein <eilong@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vladislav Zolotarov authored
This patch introduces the parity errors handling code for 57710 and 57711 chips. HW is configured to stop all DMA transactions to the host and sending packets to the network once parity error is detected, which is meant to prevent silent data corruption. At the same time HW generates the attention interrupt to every function of the device where parity has been detected so that driver can start the recovery flow. The recovery is actually resetting the chip and restarting the driver on all active functions of the chip where the parity error has been reported. Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com> Signed-off-by: Eilon Greenstein <eilong@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 18 Apr, 2010 2 commits
-
-
Eric Dumazet authored
Transmitted skb might be attached to a socket and a destructor, for memory accounting purposes. Traditionally, this destructor is called at tx completion time, when skb is freed. When tx completion is performed by another cpu than the sender, this forces some cache lines to change ownership. XPS was an attempt to give tx completion to initial cpu. David idea is to call destructor right before giving skb to device (call to ndo_start_xmit()). Because device queues are usually small, orphaning skb before tx completion is not a big deal. Some drivers already do this, we could do it in upper level. There is one known exception to this early orphaning, called tx timestamping. It needs to keep a reference to socket until device can give a hardware or software timestamp. This patch adds a skb_orphan_try() helper, to centralize all exceptions to early orphaning in one spot, and use it in dev_hard_start_xmit(). "tbench 16" results on a Nehalem machine (2 X5570 @ 2.93GHz) before: Throughput 4428.9 MB/sec 16 procs after: Throughput 4448.14 MB/sec 16 procs UDP should get even better results, its destructor being more complex, since SOCK_USE_WRITE_QUEUE is not set (four atomic ops instead of one) Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
- There is no point to enforce a time limit in process_backlog(), since other napi instances dont follow same rule. We can exit after only one packet processed... The normal quota of 64 packets per napi instance should be the norm, and net_rx_action() already has its own time limit. Note : /proc/net/core/dev_weight can be used to tune this 64 default value. - Use DEFINE_PER_CPU_ALIGNED for softnet_data definition. Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 17 Apr, 2010 1 commit
-
-
Eric Dumazet authored
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 16 Apr, 2010 4 commits
-
-
Tom Herbert authored
This patch implements receive flow steering (RFS). RFS steers received packets for layer 3 and 4 processing to the CPU where the application for the corresponding flow is running. RFS is an extension of Receive Packet Steering (RPS). The basic idea of RFS is that when an application calls recvmsg (or sendmsg) the application's running CPU is stored in a hash table that is indexed by the connection's rxhash which is stored in the socket structure. The rxhash is passed in skb's received on the connection from netif_receive_skb. For each received packet, the associated rxhash is used to look up the CPU in the hash table, if a valid CPU is set then the packet is steered to that CPU using the RPS mechanisms. The convolution of the simple approach is that it would potentially allow OOO packets. If threads are thrashing around CPUs or multiple threads are trying to read from the same sockets, a quickly changing CPU value in the hash table could cause rampant OOO packets-- we consider this a non-starter. To avoid OOO packets, this solution implements two types of hash tables: rps_sock_flow_table and rps_dev_flow_table. rps_sock_table is a global hash table. Each entry is just a CPU number and it is populated in recvmsg and sendmsg as described above. This table contains the "desired" CPUs for flows. rps_dev_flow_table is specific to each device queue. Each entry contains a CPU and a tail queue counter. The CPU is the "current" CPU for a matching flow. The tail queue counter holds the value of a tail queue counter for the associated CPU's backlog queue at the time of last enqueue for a flow matching the entry. Each backlog queue has a queue head counter which is incremented on dequeue, and so a queue tail counter is computed as queue head count + queue length. When a packet is enqueued on a backlog queue, the current value of the queue tail counter is saved in the hash entry of the rps_dev_flow_table. And now the trick: when selecting the CPU for RPS (get_rps_cpu) the rps_sock_flow table and the rps_dev_flow table for the RX queue are consulted. When the desired CPU for the flow (found in the rps_sock_flow table) does not match the current CPU (found in the rps_dev_flow table), the current CPU is changed to the desired CPU if one of the following is true: - The current CPU is unset (equal to RPS_NO_CPU) - Current CPU is offline - The current CPU's queue head counter >= queue tail counter in the rps_dev_flow table. This checks if the queue tail has advanced beyond the last packet that was enqueued using this table entry. This guarantees that all packets queued using this entry have been dequeued, thus preserving in order delivery. Making each queue have its own rps_dev_flow table has two advantages: 1) the tail queue counters will be written on each receive, so keeping the table local to interrupting CPU s good for locality. 2) this allows lockless access to the table-- the CPU number and queue tail counter need to be accessed together under mutual exclusion from netif_receive_skb, we assume that this is only called from device napi_poll which is non-reentrant. This patch implements RFS for TCP and connected UDP sockets. It should be usable for other flow oriented protocols. There are two configuration parameters for RFS. The "rps_flow_entries" kernel init parameter sets the number of entries in the rps_sock_flow_table, the per rxqueue sysfs entry "rps_flow_cnt" contains the number of entries in the rps_dev_flow table for the rxqueue. Both are rounded to power of two. The obvious benefit of RFS (over just RPS) is that it achieves CPU locality between the receive processing for a flow and the applications processing; this can result in increased performance (higher pps, lower latency). The benefits of RFS are dependent on cache hierarchy, application load, and other factors. On simple benchmarks, we don't necessarily see improvement and sometimes see degradation. However, for more complex benchmarks and for applications where cache pressure is much higher this technique seems to perform very well. Below are some benchmark results which show the potential benfit of this patch. The netperf test has 500 instances of netperf TCP_RR test with 1 byte req. and resp. The RPC test is an request/response test similar in structure to netperf RR test ith 100 threads on each host, but does more work in userspace that netperf. e1000e on 8 core Intel No RFS or RPS 104K tps at 30% CPU No RFS (best RPS config): 290K tps at 63% CPU RFS 303K tps at 61% CPU RPC test tps CPU% 50/90/99% usec latency Latency StdDev No RFS/RPS 103K 48% 757/900/3185 4472.35 RPS only: 174K 73% 415/993/2468 491.66 RFS 223K 73% 379/651/1382 315.61 Signed-off-by: Tom Herbert <therbert@google.com> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Shan Wei authored
ip6_xmit() is used by upper transport protocol. Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Shan Wei authored
As Herbert Xu said: we should be able to simply replace ipfragok with skb->local_df. commit f88037(sctp: Drop ipfargok in sctp_xmit function) has droped ipfragok and set local_df value properly. The patch kills the ipfragok parameter of .queue_xmit(). Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Shan Wei authored
commit f88037(sctp: Drop ipfargok in sctp_xmit function) has droped ipfragok and set local_df value properly. So the change of commit 77e2f1(ipv6: Fix ip6_xmit to send fragments if ipfragok is true) is not needed. So the patch remove them. Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 15 Apr, 2010 10 commits
-
-
Joe Perches authored
Signed-off-by: Joe Perches <joe@perches.com> Acked-by: James Chapman <jchapman@katalix.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6
-
-
John W. Linville authored
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6 into for-davem Conflicts: Documentation/feature-removal-schedule.txt drivers/net/wireless/ath/ath5k/phy.c drivers/net/wireless/wl12xx/wl1271_main.c
-
Patrick McHardy authored
Fix an oversight in ipmr_destroy_unres() - the net pointer is unconditionally initialized to NULL, resulting in a NULL pointer dereference later on. Fix by adding a net pointer to struct mr_table and using it in ipmr_destroy_unres(). Signed-off-by: Patrick McHardy <kaber@trash.net>
-
Patrick McHardy authored
The patch to convert struct mfc_cache to list_heads (ipv4: ipmr: convert struct mfc_cache to struct list_head) introduced a bug when adding new cache entries that don't match any unresolved entries. The unres queue is searched for a matching entry, which is then resolved. When no matching entry is present, the iterator points to the head of the list, but is treated as a matching entry. Use a seperate variable to indicate that a matching entry was found. Signed-off-by: Patrick McHardy <kaber@trash.net>
-
Patrick McHardy authored
IP_MROUTE_MULTIPLE_TABLES should depend on IP_MROUTE. Signed-off-by: Patrick McHardy <kaber@trash.net>
-
Changli Gao authored
Signed-off-by: Changli Gao <xiaosuo@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
Eric Paris reported netif_rx() is calling smp_processor_id() from preemptible context, in particular when caller is ip_dev_loopback_xmit(). RPS commit added this smp_processor_id() call, this patch makes sure preemption is disabled. rps_get_cpus() wants rcu_read_lock() anyway, we can dot it a bit earlier. Reported-by: Eric Paris <eparis@redhat.com> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
-
- 14 Apr, 2010 20 commits
-
-
Jesse Brandeburg authored
The ixgbe driver was setting up 82598 hardware correctly, so that when promiscuous mode was enabled hardware stripping was turned off. But on 82599 the logic to disable/enable hardware stripping is different, and the code was not updated correctly when the hardware vlan stripping was enabled as default. This change comprises the creation of two new helper functions and calling them from the right locations to disable and enable hardware stripping of vlan tags at appropriate times. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
replaces (skb->len - skb->data_len) occurrences by skb_headlen(skb) Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Xose Vazquez Perez authored
A very useful information was provided by Sitecom R&D guys: Please find the information regarding our latest Ralink adapters below; WL-302 - VID: 0x0DF6, PID: 0x002D - Ralink RT2771 WL-315 - VID: 0x0DF6, PID: 0x0039 - Ralink RT2770 WL-319 - VID: 0x182D, PID: 0x0037 - Ralink RT2860 WL-321 - VID: 0x0DF6, PID: 0x003B - Ralink RT2770 WL-324 - VID: 0x0DF6, PID: 0x003D - Ralink RT2870 WL-329 - VID: 0x0DF6, PID: 0x0041 - Ralink RT3572 WL-343 - VID: 0x0DF6, PID: 0x003E - Ralink RT3070 WL-344 - VID: 0x0DF6, PID: 0x0040 - Ralink RT3071 WL-345 - VID: 0x0DF6, PID: 0x0042 - Ralink RT3072 WL-608 - VID: 0x0DF6, PID: 0x003F - Ralink RT2070 Note: PID: 0x003C, 0x004A, and 0x004D: --these products do not exist; devices were never produced/shipped-- The WL-349v4 USB dongle (0x0df6,0x0050) will be shipped soon (it isn't available yet), and uses a Ralink RT3370 chipset. Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
This patch adds the following 5 entries to the usbid device table: * Netgear WNA1000 * Proxim ORiNOCO Dual Band 802.11n USB Adapter * 3Com Dual Band 802.11n USB Adapter * H3C Dual Band 802.11n USB Adapter * WNC Generic 11n USB dongle CC: <stable@kernel.org> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Grazvydas Ignotas authored
If EEPROM is used, NVS data is now loaded but ignored. Stop loading it to avoid need of dummy NVS file for modules with EEPROM. Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Acked-by: Kalle Valo <kvalo@adurom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ming Lei authored
This patch fixes two warnings below after unplugging ar9271 usb device: -one is a kernel warning[1] -another is a lockdep warning[2] The root reason is that __skb_queue_purge can't be executed in hardirq context, so the patch forks ath9k_skb_queue_purge(ath9k version of _skb_queue_purge), which frees skb with dev_kfree_skb_any which can be run in hardirq context safely, then prevent the lockdep warning and kernel warning after unplugging ar9271 usb device. [1] kernel warning [ 602.894005] ------------[ cut here ]------------ [ 602.894005] WARNING: at net/core/skbuff.c:398 skb_release_head_state+0x71/0x87() [ 602.894005] Hardware name: 6475EK2 [ 602.894005] Modules linked in: ath9k_htc ath9k ath9k_common ath9k_hw ath bridge stp llc sunrpc ipv6 cpufreq_ondemand acpi_cpufreq freq_table kvm_intel kvm arc4 ecb mac80211 snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep thinkpad_acpi snd_pcm snd_timer hwmon iTCO_wdt snd e1000e pcspkr i2c_i801 usbhid iTCO_vendor_support wmi cfg80211 yenta_socket rsrc_nonstatic pata_acpi snd_page_alloc soundcore uhci_hcd ohci_hcd ehci_hcd usbcore i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: ath] [ 602.894005] Pid: 2506, comm: ping Tainted: G W 2.6.34-rc3-wl #20 [ 602.894005] Call Trace: [ 602.894005] <IRQ> [<ffffffff8104a41c>] warn_slowpath_common+0x7c/0x94 [ 602.894005] [<ffffffffa022f398>] ? __skb_queue_purge+0x43/0x4a [ath9k_htc] [ 602.894005] [<ffffffff8104a448>] warn_slowpath_null+0x14/0x16 [ 602.894005] [<ffffffff813269c1>] skb_release_head_state+0x71/0x87 [ 602.894005] [<ffffffff8132829a>] __kfree_skb+0x16/0x81 [ 602.894005] [<ffffffff813283b2>] kfree_skb+0x7e/0x86 [ 602.894005] [<ffffffffa022f398>] __skb_queue_purge+0x43/0x4a [ath9k_htc] [ 602.894005] [<ffffffffa022f560>] __hif_usb_tx+0x1c1/0x21b [ath9k_htc] [ 602.894005] [<ffffffffa022f73c>] hif_usb_tx_cb+0x12f/0x154 [ath9k_htc] [ 602.894005] [<ffffffffa00d2fbe>] usb_hcd_giveback_urb+0x91/0xc5 [usbcore] [ 602.894005] [<ffffffffa00f6c34>] ehci_urb_done+0x7a/0x8b [ehci_hcd] [ 602.894005] [<ffffffffa00f6f33>] qh_completions+0x2ee/0x376 [ehci_hcd] [ 602.894005] [<ffffffffa00f8ba5>] ehci_work+0x95/0x76e [ehci_hcd] [ 602.894005] [<ffffffffa00fa5ae>] ? ehci_irq+0x2f/0x1d4 [ehci_hcd] [ 602.894005] [<ffffffffa00fa725>] ehci_irq+0x1a6/0x1d4 [ehci_hcd] [ 602.894005] [<ffffffff810a6d18>] ? __rcu_process_callbacks+0x7a/0x2df [ 602.894005] [<ffffffff810a47a4>] ? handle_fasteoi_irq+0x22/0xd2 [ 602.894005] [<ffffffffa00d268d>] usb_hcd_irq+0x4a/0xa7 [usbcore] [ 602.894005] [<ffffffff810a2853>] handle_IRQ_event+0x77/0x14f [ 602.894005] [<ffffffff813285ce>] ? skb_release_data+0xc9/0xce [ 602.894005] [<ffffffff810a4814>] handle_fasteoi_irq+0x92/0xd2 [ 602.894005] [<ffffffff8100c4fb>] handle_irq+0x88/0x91 [ 602.894005] [<ffffffff8100baed>] do_IRQ+0x63/0xc9 [ 602.894005] [<ffffffff81354245>] ? ip_flush_pending_frames+0x4d/0x5c [ 602.894005] [<ffffffff813ba993>] ret_from_intr+0x0/0x16 [ 602.894005] <EOI> [<ffffffff811095fe>] ? __delete_object+0x5a/0xb1 [ 602.894005] [<ffffffff813ba5f5>] ? _raw_write_unlock_irqrestore+0x47/0x7e [ 602.894005] [<ffffffff813ba5fa>] ? _raw_write_unlock_irqrestore+0x4c/0x7e [ 602.894005] [<ffffffff811095fe>] __delete_object+0x5a/0xb1 [ 602.894005] [<ffffffff81109814>] delete_object_full+0x25/0x31 [ 602.894005] [<ffffffff813a60c0>] kmemleak_free+0x26/0x45 [ 602.894005] [<ffffffff810ff517>] kfree+0xaa/0x149 [ 602.894005] [<ffffffff81323fb7>] ? sock_def_write_space+0x84/0x89 [ 602.894005] [<ffffffff81354245>] ? ip_flush_pending_frames+0x4d/0x5c [ 602.894005] [<ffffffff813285ce>] skb_release_data+0xc9/0xce [ 602.894005] [<ffffffff813282a2>] __kfree_skb+0x1e/0x81 [ 602.894005] [<ffffffff813283b2>] kfree_skb+0x7e/0x86 [ 602.894005] [<ffffffff81354245>] ip_flush_pending_frames+0x4d/0x5c [ 602.894005] [<ffffffff81370c1f>] raw_sendmsg+0x653/0x709 [ 602.894005] [<ffffffff81379e31>] inet_sendmsg+0x54/0x5d [ 602.894005] [<ffffffff813207a2>] ? sock_recvmsg+0xc6/0xdf [ 602.894005] [<ffffffff813208c1>] sock_sendmsg+0xc0/0xd9 [ 602.894005] [<ffffffff810e13b4>] ? might_fault+0x68/0xb8 [ 602.894005] [<ffffffff810e13fd>] ? might_fault+0xb1/0xb8 [ 602.894005] [<ffffffff8132a1c3>] ? copy_from_user+0x2f/0x31 [ 602.894005] [<ffffffff8132a5b3>] ? verify_iovec+0x54/0x91 [ 602.894005] [<ffffffff81320d41>] sys_sendmsg+0x1da/0x241 [ 602.894005] [<ffffffff8103d327>] ? finish_task_switch+0x0/0xc9 [ 602.894005] [<ffffffff8103d327>] ? finish_task_switch+0x0/0xc9 [ 602.894005] [<ffffffff8107642e>] ? trace_hardirqs_on_caller+0x16/0x150 [ 602.894005] [<ffffffff813ba27d>] ? _raw_spin_unlock_irq+0x56/0x63 [ 602.894005] [<ffffffff8103d3cb>] ? finish_task_switch+0xa4/0xc9 [ 602.894005] [<ffffffff8103d327>] ? finish_task_switch+0x0/0xc9 [ 602.894005] [<ffffffff810357fe>] ? need_resched+0x23/0x2d [ 602.894005] [<ffffffff8107642e>] ? trace_hardirqs_on_caller+0x16/0x150 [ 602.894005] [<ffffffff813b9750>] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 602.894005] [<ffffffff81009c02>] system_call_fastpath+0x16/0x1b [ 602.894005] ---[ end trace 91ba2d8dc7826839 ]--- [2] lockdep warning [ 169.363215] ====================================================== [ 169.365390] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ] [ 169.366334] 2.6.34-rc3-wl #20 [ 169.366872] ------------------------------------------------------ [ 169.366872] khubd/78 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 169.366872] (clock-AF_INET){++.?..}, at: [<ffffffff81323f51>] sock_def_write_space+0x1e/0x89 [ 169.366872] [ 169.366872] and this task is already holding: [ 169.366872] (&(&hif_dev->tx.tx_lock)->rlock){-.-...}, at: [<ffffffffa03715b0>] hif_usb_stop+0x24/0x53 [ath9k_htc] [ 169.366872] which would create a new lock dependency: [ 169.366872] (&(&hif_dev->tx.tx_lock)->rlock){-.-...} -> (clock-AF_INET){++.?..} [ 169.366872] [ 169.366872] but this new dependency connects a HARDIRQ-irq-safe lock: [ 169.366872] (&(&hif_dev->tx.tx_lock)->rlock){-.-...} [ 169.366872] ... which became HARDIRQ-irq-safe at: [ 169.366872] [<ffffffff810772d5>] __lock_acquire+0x2c6/0xd2b [ 169.366872] [<ffffffff8107866d>] lock_acquire+0xec/0x119 [ 169.366872] [<ffffffff813b99bb>] _raw_spin_lock+0x40/0x73 [ 169.366872] [<ffffffffa037163d>] hif_usb_tx_cb+0x5e/0x154 [ath9k_htc] [ 169.366872] [<ffffffffa00d2fbe>] usb_hcd_giveback_urb+0x91/0xc5 [usbcore] [ 169.366872] [<ffffffffa00f6c34>] ehci_urb_done+0x7a/0x8b [ehci_hcd] [ 169.366872] [<ffffffffa00f6f33>] qh_completions+0x2ee/0x376 [ehci_hcd] [ 169.366872] [<ffffffffa00f8ba5>] ehci_work+0x95/0x76e [ehci_hcd] [ 169.366872] [<ffffffffa00fa725>] ehci_irq+0x1a6/0x1d4 [ehci_hcd] [ 169.366872] [<ffffffffa00d268d>] usb_hcd_irq+0x4a/0xa7 [usbcore] [ 169.366872] [<ffffffff810a2853>] handle_IRQ_event+0x77/0x14f [ 169.366872] [<ffffffff810a4814>] handle_fasteoi_irq+0x92/0xd2 [ 169.366872] [<ffffffff8100c4fb>] handle_irq+0x88/0x91 [ 169.366872] [<ffffffff8100baed>] do_IRQ+0x63/0xc9 [ 169.366872] [<ffffffff813ba993>] ret_from_intr+0x0/0x16 [ 169.366872] [<ffffffff8130f6ee>] cpuidle_idle_call+0xa7/0x115 [ 169.366872] [<ffffffff81008c4f>] cpu_idle+0x68/0xc4 [ 169.366872] [<ffffffff813a41e0>] rest_init+0x104/0x10b [ 169.366872] [<ffffffff81899db3>] start_kernel+0x3f1/0x3fc [ 169.366872] [<ffffffff818992c8>] x86_64_start_reservations+0xb3/0xb7 [ 169.366872] [<ffffffff818993c4>] x86_64_start_kernel+0xf8/0x107 [ 169.366872] [ 169.366872] to a HARDIRQ-irq-unsafe lock: [ 169.366872] (clock-AF_INET){++.?..} [ 169.366872] ... which became HARDIRQ-irq-unsafe at: [ 169.366872] ... [<ffffffff81077349>] __lock_acquire+0x33a/0xd2b [ 169.366872] [<ffffffff8107866d>] lock_acquire+0xec/0x119 [ 169.366872] [<ffffffff813b9d07>] _raw_write_lock_bh+0x45/0x7a [ 169.366872] [<ffffffff8135cf14>] tcp_close+0x165/0x34d [ 169.366872] [<ffffffff8137aced>] inet_release+0x55/0x5c [ 169.366872] [<ffffffff81321350>] sock_release+0x1f/0x6e [ 169.366872] [<ffffffff813213c6>] sock_close+0x27/0x2b [ 169.366872] [<ffffffff8110dd45>] __fput+0x125/0x1ca [ 169.366872] [<ffffffff8110de04>] fput+0x1a/0x1c [ 169.366872] [<ffffffff8110adc9>] filp_close+0x68/0x72 [ 169.366872] [<ffffffff8110ae80>] sys_close+0xad/0xe7 [ 169.366872] [<ffffffff81009c02>] system_call_fastpath+0x16/0x1b (Trimmed at the "other info that might help us debug this" line in the interest of brevity... -- JWL) Signed-off-by: Ming Lei <tom.leiming@gmail.com> Acked-by: Sujith <Sujith.Manoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ming Lei authored
In ath9k-htc register out path, ath9k-htc will pass skb->data into usb hcd and usb hcd will do dma mapping and unmapping to the buffer pointed by skb->data, so we should pass a cache-line aligned address. This patch replace __dev_alloc_skb with alloc_skb to make skb->data pointed to a cacheline aligned address simply since ath9k-htc does not skb_push on the skb and pass it to mac80211, also use kfree_skb to free the skb allocated by alloc_skb(we can use kfree_skb safely in hardirq context since skb->destructor is NULL always in the path). Signed-off-by: Sujith <Sujith.Manoharan@atheros.com> Signed-off-by: Ming Lei <tom.leiming@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ming Lei authored
In ath9k-htc register in path, ath9k-htc will pass skb->data into usb hcd and usb hcd will do dma mapping and unmapping to the buffer pointed by skb->data, so we should pass a cache-line aligned address. This patch replace __dev_alloc_skb with alloc_skb to make skb->data pointed to a cacheline aligned address simply since ath9k-htc does not skb_push on the skb and pass it to mac80211, also use kfree_skb to free the skb allocated by alloc_skb(we can use kfree_skb safely in hardirq context since skb->destructor is NULL always in the path). Signed-off-by: Ming Lei <tom.leiming@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ming Lei authored
In ath9k_hif_usb_alloc_rx_urbs, ath9k-htc will pass skb->data into usb hcd and usb hcd will do dma mapping and unmapping to the buffer pointed by skb->data, so we should pass a cache-line aligned address. This patch replace __dev_alloc_skb with alloc_skb to make skb->data pointed to a cacheline aligned address simply since ath9k-htc does not skb_push on the skb and pass it to mac80211, also use kfree_skb to free the skbs allocated by alloc_skb(we can use kfree_skb safely in hardirq context since skb->destructor is NULL always in the path). Signed-off-by: Ming Lei <tom.leiming@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
We get RXORN interrupts when all receive buffers are full. This is not necessarily a fatal situation. It can also happen when the bus is busy or the CPU is not fast enough to process all frames. Older chipsets apparently need a reset to come out of this situration, but on newer chips we can treat RXORN like RX, as going thru a full reset does more harm than good, there. The exact chip revisions which need a reset are unknown - this guess AR5K_SREV_AR5212 ("venice") is copied from the HAL. Inspired by openwrt 413-rxorn.patch: "treat rxorn like rx, reset after rxorn seems to do more harm than good" Signed-off-by: Bruno Randolf <br1@einfach.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
There was a confusion in the usage of the bits AR5K_STA_ID1_ACKCTS_6MB and AR5K_STA_ID1_BASE_RATE_11B. If they are set (1), we will get lower bitrates for ACK and CTS. Therefore ath5k_hw_set_ack_bitrate_high(ah, false) actually resulted in high bitrates, which i think is what we want anyways. Cleared the confusion and added some documentation. Signed-off-by: Bruno Randolf <br1@einfach.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
David S. Miller authored
Pointed out by Stephen Rothwell. Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Conflicts: drivers/net/pcmcia/smc91c92_cs.c drivers/net/virtio_net.c
-
Michael S. Tsirkin authored
The following situation was observed in the field: tap1 sends packets, tap2 does not consume them, as a result tap1 can not be closed. This happens because tun/tap devices can hang on to skbs undefinitely. As noted by Herbert, possible solutions include a timeout followed by a copy/change of ownership of the skb, or always copying/changing ownership if we're going into a hostile device. This patch implements the second approach. Note: one issue still remaining is that since skbs keep reference to tun socket and tun socket has a reference to tun device, we won't flush backlog, instead simply waiting for all skbs to get transmitted. At least this is not user-triggerable, and this was not reported in practice, my assumption is other devices besides tap complete an skb within finite time after it has been queued. A possible solution for the second issue would not to have socket reference the device, instead, implement dev->destructor for tun, and wait for all skbs to complete there, but this needs some thought, probably too risky for 2.6.34. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Yan Vugenfirer <yvugenfi@redhat.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Giuseppe CAVALLARO authored
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Giuseppe CAVALLARO authored
Moved STMMAC_VLAN_TAG_USED from stmmac.h to common.h header because it is used within the device and descriptor cores. Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Giuseppe CAVALLARO authored
Output for chip that uses the Enhanced descriptors: [snip] STMMAC driver: platform registration... done! DWMAC1000 - user ID: 0x10, Synopsys ID: 0x33 Enhanced descriptor structure no valid MAC address;please, use ifconfig or nwhwconfig! eth0 - (dev. name: stmmaceth - id: 0, IRQ #134 IO base addr: 0xfd110000) STMMAC MII Bus: probed [snip] Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Giuseppe CAVALLARO authored
The new enh_desc is used for selecting the enhanced descriptors structure. There are several scenarios; some chips (mac10/100 or gmac) want to use the enhanced descriptors; others want the normal ones. For example, on ST platforms: MAC10/100 uses the normal desc structure and the GMAC uses the enhanced one. It can be useful to get this information from the platform. This could also be decided at run-time looking at the chip's ID number; but it could happen that chips with the same ID want to use different descriptor structure. Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Giuseppe CAVALLARO authored
Fix the Transmit FIFO flush operation; it was disabled while reworking the descriptor structures. Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Giuseppe CAVALLARO authored
Currently the driver assumes that the mac10/100 can only use the normal descriptor structure and the gmac can only use the enhanced structures. This patch removes the descriptor's code from the dma files and adds two new files just for handling the normal and enhanced descriptors. Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-