- 01 Apr, 2010 40 commits
-
-
Clemens Ladisch authored
commit 1082f57a upstream. The EHCI driver stores in usb_host_endpoint.hcpriv a pointer to either an ehci_qh or an ehci_iso_stream structure, and uses the contents of the hw_info1 field to distinguish the two cases. After ehci_qh was split into hw and sw parts, ehci_iso_stream must also be adjusted so that it again looks like an ehci_qh structure. This fixes a NULL pointer access in ehci_endpoint_disable() when it tries to access qh->hw->hw_info1. Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Reported-by:
Colin Fletcher <colin.m.fletcher@googlemail.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Clemens Ladisch authored
commit 92bc3648 upstream. When isochronous URBs are shorter than one frame and when more than one ITD in a frame has been completed before the interrupt can be handled, scan_periodic() completes the URBs in the order in which they are found in the descriptor list. Therefore, the descriptor list must contain the ITDs in the correct order, i.e., a new ITD must be linked in after any previous ITDs of the same endpoint. This should fix garbled capture data in the USB audio drivers. Signed-off-by:
-
Alan Stern authored
commit 7152b592 upstream. This patch (as1352) fixes a bug in the way isochronous input data is returned to userspace for usbfs transfers. The entire buffer must be copied, not just the first actual_length bytes, because the individual packets will be discontiguous if any of them are short. Reported-by:
Markus Rechberger <mrechberger@gmail.com> Signed-off-by:
-
Mel Gorman authored
commit 352fa6ad upstream. The TTY layer takes some care to ensure that only sub-page allocations are made with interrupts disabled. It does this by setting a goal of "TTY_BUFFER_PAGE" to allocate. Unfortunately, while TTY_BUFFER_PAGE takes the size of tty_buffer into account, it fails to account that tty_buffer_find() rounds the buffer size out to the next 256 byte boundary before adding on the size of the tty_buffer. This patch adjusts the TTY_BUFFER_PAGE calculation to take into account the size of the tty_buffer and the padding. Once applied, tty_buffer_alloc() should not require high-order allocations. Signed-off-by:
Mel Gorman <mel@csn.ul.ie> Signed-off-by:
-
Alan Cox authored
commit d9661adf upstream. We allocate during interrupts so while our buffering is normally diced up small anyway on some hardware at speed we can pressure the VM excessively for page pairs. We don't really need big buffers to be linear so don't try so hard. In order to make this work well we will tidy up excess callers to request_room, which cannot itself enforce this break up. Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Trond Myklebust authored
commit d812e575 upstream. We should not attempt to free the page if __GFP_FS is not set. Otherwise we can deadlock as per http://bugzilla.kernel.org/show_bug.cgi?id=15578Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Trond Myklebust authored
commit bb6fbc45 upstream. J.R. Okajima reports the following deadlock: INFO: task kswapd0:305 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kswapd0 D 0000000000000001 0 305 2 0x00000000 ffff88001f21d4f0 0000000000000046 ffff88001fdea680 ffff88001f21c000 ffff88001f21dfd8 ffff88001f21c000 ffff88001f21dfd8 ffff88001f21dfd8 ffff88001fdea040 0000000000014c00 0000000000000001 ffff88001fdea040 Call Trace: [<ffffffff8146155d>] io_schedule+0x4d/0x70 [<ffffffff810d2be5>] sync_page+0x65/0xa0 [<ffffffff81461b12>] __wait_on_bit_lock+0x52/0xb0 [<ffffffff810d2b80>] ? sync_page+0x0/0xa0 [<ffffffff810d2b64>] __lock_page+0x64/0x70 [<ffffffff81070ce0>] ? wake_bit_function+0x0/0x40 [<ffffffff810df1d4>] truncate_inode_pages_range+0x344/0x4a0 [<ffffffff810df340>] truncate_inode_pages+0x10/0x20 [<ffffffff8112cbfe>] generic_delete_inode+0x15e/0x190 [<ffffffff8112cc8d>] generic_drop_inode+0x5d/0x80 [<ffffffff8112bb88>] iput+0x78/0x80 [<ffffffff811bc908>] nfs_dentry_iput+0x38/0x50 [<ffffffff811285f4>] dentry_iput+0x84/0x110 [<ffffffff811286ae>] d_kill+0x2e/0x60 [<ffffffff8112912a>] dput+0x7a/0x170 [<ffffffff8111e925>] path_put+0x15/0x40 [<ffffffff811c3a44>] __put_nfs_open_context+0xa4/0xb0 [<ffffffff811cb5d0>] ? nfs_free_request+0x0/0x50 [<ffffffff811c3b0b>] put_nfs_open_context+0xb/0x10 [<ffffffff811cb5f9>] nfs_free_request+0x29/0x50 [<ffffffff81234b7e>] kref_put+0x8e/0xe0 [<ffffffff811cb594>] nfs_release_request+0x14/0x20 [<ffffffff811cf769>] nfs_find_and_lock_request+0x89/0xa0 [<ffffffff811d1180>] nfs_wb_page+0x80/0x110 [<ffffffff811c0770>] nfs_release_page+0x70/0x90 [<ffffffff810d18ee>] try_to_release_page+0x5e/0x80 [<ffffffff810e1178>] shrink_page_list+0x638/0x860 [<ffffffff810e19de>] shrink_zone+0x63e/0xc40 We can fix this by making the call to put_nfs_open_context() happen when we actually remove the write request from the inode (which is done by the nfsiod thread in this case). Signed-off-by:
-
Trond Myklebust authored
commit b4d2314b upstream. If the NFS_INO_REVAL_FORCED flag is set, that means that we don't yet have an up to date attribute cache. Even if we hold a delegation, we must put a GETATTR on the wire. Signed-off-by:
-
Gal Rosen authored
commit 0d9dc7c8 upstream. The issue occur while deleting 60 virtual ports through the sys interface /sys/class/fc_vports/vport-X/vport_delete. It happen while in a mistake each request sent twice for the same vport. This interface is asynchronous, entering the delete request into a work queue, allowing more than one request to enter to the delete work queue. The result is a NULL pointer. The first request already delete the vport, while the second request got a pointer to the vport before the device destroyed. Re-create vport later cause system freeze. Solution: Check vport flags before entering the request to the work queue. [jejb: fixed int<->long problem on spinlock flags variable] Signed-off-by:
Gal Rosen <galr@storwize.com> Acked-by:
James Smart <james.smart@emulex.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Signed-off-by:
-
KOSAKI Motohiro authored
commit 55741696 upstream. commit 3f226aa1 (mempolicy: support mpol=local tmpfs mount option) added new mpol=local mount option. but it didn't add a documentation. This patch does it. Signed-off-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Ravikiran Thirumalai <kiran@scalex86.org> Cc: Christoph Lameter <cl@linux-foundation.org> Cc: Mel Gorman <mel@csn.ul.ie> Acked-by:
Lee Schermerhorn <lee.schermerhorn@hp.com> Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
KOSAKI Motohiro authored
commit 926f2ae0 upstream. mpol_parse_str() made lots 'err' variable related bug. Because it is ugly and reviewing unfriendly. This patch simplifies it. Signed-off-by:
-
KOSAKI Motohiro authored
commit 12821f5f upstream. commit 71fe804b (mempolicy: use struct mempolicy pointer in shmem_sb_info) added mpol=local mount option. but its feature is broken since it was born. because such code always return 1 (i.e. mount failure). This patch fixes it. Signed-off-by:
-
KOSAKI Motohiro authored
commit d69b2e63 upstream. Currently, following mount operation cause mount error. % mount -t tmpfs -ompol=bind:0 none /tmp Because commit 71fe804b (mempolicy: use struct mempolicy pointer in shmem_sb_info) corrupted MPOL_BIND parse code. This patch restore the needed one. Signed-off-by:
-
Ravikiran G Thirumalai authored
commit 413b43de upstream. Fix an 'oops' when a tmpfs mount point is mounted with the mpol=default mempolicy. Upon remounting a tmpfs mount point with 'mpol=default' option, the mount code crashed with a null pointer dereference. The initial problem report was on 2.6.27, but the problem exists in mainline 2.6.34-rc as well. On examining the code, we see that mpol_new returns NULL if default mempolicy was requested. This 'NULL' mempolicy is accessed to store the node mask resulting in oops. The following patch fixes it. Signed-off-by:
Ravikiran Thirumalai <kiran@scalex86.org> Signed-off-by:
-
Paul Mackerras authored
commit 220b140b upstream. Anton Blanchard found that he could reliably make the kernel hit a BUG_ON in the slab allocator by taking a cpu offline and then online while a system-wide perf record session was running. The reason is that when the cpu comes up, we completely reinitialize the ctx field of the struct perf_cpu_context for the cpu. If there is a system-wide perf record session running, then there will be a struct perf_event that has a reference to the context, so its refcount will be 2. (The perf_event has been removed from the context's group_entry and event_entry lists by perf_event_exit_cpu(), but that doesn't remove the perf_event's reference to the context and doesn't decrement the context's refcount.) When the cpu comes up, perf_event_init_cpu() gets called, and it calls __perf_event_init_context() on the cpu's context. That resets the refcount to 1. Then when the perf record session finishes and the perf_event is closed, the refcount gets decremented to 0 and the context gets kfreed after an RCU grace period. Since the context wasn't kmalloced -- it's part of a per-cpu variable -- bad things happen. In fact we don't need to completely reinitialize the context when the cpu comes up. It's sufficient to initialize the context once at boot, but we need to do it for all possible cpus. This moves the context initialization to happen at boot time. With this, we don't trash the refcount and the context never gets kfreed, and we don't hit the BUG_ON. Reported-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Paul Mackerras <paulus@samba.org> Tested-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
John Kacur authored
commit 7ae5f213 upstream. Without this change, the install path is relative to prefix/DESTDIR where prefix is automatically set to $HOME. This can produce unexpected results. For example: make -C tools/perf DESTDIR=/home/jkacur/tmp install-man creates the directory: /home/jkacur/home/jkacur/tmp/share/... instead of the expected: /home/jkacur/tmp/share/... Signed-off-by:
John Kacur <jkacur@redhat.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Tom Zanussi <tzanussi@gmail.com> Cc: Kyle McMartin <kyle@redhat.com> LKML-Reference: <1268312220-12880-1-git-send-email-jkacur@redhat.com> Signed-off-by:
-
Tilman Schmidt authored
commit 873a69a3 upstream. Calling tty_buffer_request_room() before tty_insert_flip_string() is unnecessary, costs CPU and for big buffers can mess up the multi-page allocation avoidance. Signed-off-by:
Tilman Schmidt <tilman@imap.cc> Acked-by:
Karsten Keil <keil@b1-systems.de> CC: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Tilman Schmidt authored
commit 3a0a3a6b upstream. In RING handling, clear the table of received parameter strings in a loop like everywhere else, instead of by enumeration which had already gotten out of sync. Impact: minor bugfix Signed-off-by:
-
Clemens Ladisch authored
commit 1c583063 upstream. When the CMI8738 FRAME2 register is read, the chip sometimes (probably when wrapping around) returns an invalid value that would be outside the programmed DMA buffer. This leads to an inconsistent PCM pointer that is likely to result in an underrun. To work around this, read the register multiple times until we get a valid value; the error state seems to be very short-lived. Signed-off-by:
Matija Nalis <mnalis-alsadev@voyager.hr> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Daniel T Chen authored
commit 025f206c upstream. BugLink: https://launchpad.net/bugs/420578 The OR has verified that his hardware distorts because of the 0 dB offset not corresponding to the highest PCM level. Fix this by capping said PCM level to 0 dB similarly to what we do for CX20549 (Venice). Reported-by:
Mike Pontillo <pontillo@gmail.com> Tested-by:
Daniel T Chen <crimsun@ubuntu.com> Signed-off-by:
-
Takashi Iwai authored
commit 9c4cc0bd upstream. Fix adc_nids[] for ALC260 basic model to match with num_adc_nids. Otherwise you get an invalid NID in the secondary "Input Source" mixer element. Signed-off-by:
-
Takashi Iwai authored
commit 80c43ed7 upstream. Judging from the member of enable_msi white-list, Nvidia controller seems to cause troubles with MSI enabled, e.g. boot hang up or other serious issue may come up. It's safer to disable MSI as default for Nvidia controllers again for now. Signed-off-by:
-
Daniel T Chen authored
commit 572c0e3c upstream. BugLink: https://bugs.launchpad.net/bugs/538895 The OR has verified that both position_fix=1 and model=6stack-dig are necessary to have capture function properly. (The existing 3stack-6ch model quirk seems to be incorrect.) Reported-by:
Reuben Bailey <reuben.e.bailey@gmail.com> Tested-by:
-
Hisashi Hifumi authored
commit 65a80b4c upstream. I added blk_run_backing_dev on page_cache_async_readahead so readahead I/O is unpluged to improve throughput on especially RAID environment. The normal case is, if page N become uptodate at time T(N), then T(N) <= T(N+1) holds. With RAID (and NFS to some degree), there is no strict ordering, the data arrival time depends on runtime status of individual disks, which breaks that formula. So in do_generic_file_read(), just after submitting the async readahead IO request, the current page may well be uptodate, so the page won't be locked, and the block device won't be implicitly unplugged: if (PageReadahead(page)) page_cache_async_readahead() if (!PageUptodate(page)) goto page_not_up_to_date; //... page_not_up_to_date: lock_page_killable(page); Therefore explicit unplugging can help. Following is the test result with dd. #dd if=testdir/testfile of=/dev/null bs=16384 -2.6.30-rc6 1048576+0 records in 1048576+0 records out 17179869184 bytes (17 GB) copied, 224.182 seconds, 76.6 MB/s -2.6.30-rc6-patched 1048576+0 records in 1048576+0 records out 17179869184 bytes (17 GB) copied, 206.465 seconds, 83.2 MB/s (7Disks RAID-0 Array) -2.6.30-rc6 1054976+0 records in 1054976+0 records out 17284726784 bytes (17 GB) copied, 212.233 seconds, 81.4 MB/s -2.6.30-rc6-patched 1054976+0 records out 17284726784 bytes (17 GB) copied, 198.878 seconds, 86.9 MB/s (7Disks RAID-5 Array) The patch was found to improve performance with the SCST scsi target driver. See http://sourceforge.net/mailarchive/forum.php?thread_name=a0272b440906030714g67eabc5k8f847fb1e538cc62%40mail.gmail.com&forum_name=scst-devel [akpm@linux-foundation.org: unbust comment layout] [akpm@linux-foundation.org: "fix" CONFIG_BLOCK=n] Signed-off-by:
Hisashi Hifumi <hifumi.hisashi@oss.ntt.co.jp> Acked-by:
Wu Fengguang <fengguang.wu@intel.com> Cc: Jens Axboe <jens.axboe@oracle.com> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Tested-by:
Ronald <intercommit@gmail.com> Cc: Bart Van Assche <bart.vanassche@gmail.com> Cc: Vladislav Bolkhovitin <vst@vlnb.net> Cc: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
-
Suresh Siddha authored
commit dd5feea1 upstream On platforms like dual socket quad-core platform, the scheduler load balancer is not detecting the load imbalances in certain scenarios. This is leading to scenarios like where one socket is completely busy (with all the 4 cores running with 4 tasks) and leaving another socket completely idle. This causes performance issues as those 4 tasks share the memory controller, last-level cache bandwidth etc. Also we won't be taking advantage of turbo-mode as much as we would like, etc. Some of the comparisons in the scheduler load balancing code are comparing the "weighted cpu load that is scaled wrt sched_group's cpu_power" with the "weighted average load per task that is not scaled wrt sched_group's cpu_power". While this has probably been broken for a longer time (for multi socket numa nodes etc), the problem got aggrevated via this recent change: | | commit f93e65c1 | Author: Peter Zijlstra <a.p.zijlstra@chello.nl> | Date: Tue Sep 1 10:34:32 2009 +0200 | | sched: Restore __cpu_power to a straight sum of power | Also with this change, the sched group cpu power alone no longer reflects the group capacity that is needed to implement MC, MT performance (default) and power-savings (user-selectable) policies. We need to use the computed group capacity (sgs.group_capacity, that is computed using the SD_PREFER_SIBLING logic in update_sd_lb_stats()) to find out if the group with the max load is above its capacity and how much load to move etc. Reported-by:
Ma Ling <ling.ma@intel.com> Initial-Analysis-by:
Zhang, Yanmin <yanmin_zhang@linux.intel.com> Signed-off-by:
Suresh Siddha <suresh.b.siddha@intel.com> [ -v2: build fix ] Signed-off-by:
-
Oleg Nesterov authored
commit 1252f238 upstream. 05d43ed8 "x86: get rid of the insane TIF_ABI_PENDING bit" forgot about force_personality32. Fix. Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
-
Michael S. Tsirkin authored
commit 31198159 upstream. I have observed the following error on virtio-net module unload: ------------[ cut here ]------------ WARNING: at kernel/irq/manage.c:858 __free_irq+0xa0/0x14c() Hardware name: Bochs Trying to free already-free IRQ 0 Modules linked in: virtio_net(-) virtio_blk virtio_pci virtio_ring virtio af_packet e1000 shpchp aacraid uhci_hcd ohci_hcd ehci_hcd [last unloaded: scsi_wait_scan] Pid: 1957, comm: rmmod Not tainted 2.6.33-rc8-vhost #24 Call Trace: [<ffffffff8103e195>] warn_slowpath_common+0x7c/0x94 [<ffffffff8103e204>] warn_slowpath_fmt+0x41/0x43 [<ffffffff810a7a36>] ? __free_pages+0x5a/0x70 [<ffffffff8107cc00>] __free_irq+0xa0/0x14c [<ffffffff8107cceb>] free_irq+0x3f/0x65 [<ffffffffa0081424>] vp_del_vqs+0x81/0xb1 [virtio_pci] [<ffffffffa0091d29>] virtnet_remove+0xda/0x10b [virtio_net] [<ffffffffa0075200>] virtio_dev_remove+0x22/0x4a [virtio] [<ffffffff812709ee>] __device_release_driver+0x66/0xac [<ffffffff81270ab7>] driver_detach+0x83/0xa9 [<ffffffff8126fc66>] bus_remove_driver+0x91/0xb4 [<ffffffff81270fcf>] driver_unregister+0x6c/0x74 [<ffffffffa0075418>] unregister_virtio_driver+0xe/0x10 [virtio] [<ffffffffa0091c4d>] fini+0x15/0x17 [virtio_net] [<ffffffff8106997b>] sys_delete_module+0x1c3/0x230 [<ffffffff81007465>] ? old_ich_force_enable_hpet+0x117/0x164 [<ffffffff813bb720>] ? do_page_fault+0x29c/0x2cc [<ffffffff81028e58>] sysenter_dispatch+0x7/0x27 ---[ end trace 15e88e4c576cc62b ]--- The bug is in virtio-pci: we use msix_vector as array index to get irq entry, but some vqs do not have a dedicated vector so this causes an out of bounds access. By chance, we seem to often get 0 value, which results in this error. Fix by verifying that vector is legal before using it as index. Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Acked-by:
Anthony Liguori <aliguori@us.ibm.com> Acked-by:
Shirley Ma <xma@us.ibm.com> Acked-by:
Amit Shah <amit.shah@redhat.com> Signed-off-by:
-
André Goddard Rosa authored
commit 4294a8ee upstream. We leak fd on lookup_one_len() failure Signed-off-by:
André Goddard Rosa <andre.goddard@gmail.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Ming Lei authored
commit a9f042cb upstream. Since txq->axq_lock may be hold in softirq context, it must be acquired with spin_lock_bh() instead of spin_lock() if softieq is enabled. The patch fixes the lockdep warning below when unloading ath9k modules. ================================= [ INFO: inconsistent lock state ] 2.6.33-wl #12 --------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. rmmod/3642 [HC0[0]:SC0[0]:HE1:SE1] takes: (&(&txq->axq_lock)->rlock){+.?...}, at: [<ffffffffa03568c3>] ath_tx_node_cleanup+0x62/0x180 [ath9k] {IN-SOFTIRQ-W} state was registered at: [<ffffffff8107577d>] __lock_acquire+0x2f6/0xd35 [<ffffffff81076289>] lock_acquire+0xcd/0xf1 [<ffffffff813a7486>] _raw_spin_lock_bh+0x3b/0x6e [<ffffffffa0356b49>] spin_lock_bh+0xe/0x10 [ath9k] [<ffffffffa0358ec7>] ath_tx_tasklet+0xcd/0x391 [ath9k] [<ffffffffa0354f5f>] ath9k_tasklet+0x70/0xc8 [ath9k] [<ffffffff8104e601>] tasklet_action+0x8c/0xf4 [<ffffffff8104f459>] __do_softirq+0xf8/0x1cd [<ffffffff8100ab1c>] call_softirq+0x1c/0x30 [<ffffffff8100c2cf>] do_softirq+0x4b/0xa3 [<ffffffff8104f045>] irq_exit+0x4a/0x8c [<ffffffff813acccc>] do_IRQ+0xac/0xc3 [<ffffffff813a7d53>] ret_from_intr+0x0/0x16 [<ffffffff81302d52>] cpuidle_idle_call+0x9e/0xf8 [<ffffffff81008be7>] cpu_idle+0x62/0x9d [<ffffffff81391c1a>] rest_init+0x7e/0x80 [<ffffffff818bbd38>] start_kernel+0x3e8/0x3f3 [<ffffffff818bb2bc>] x86_64_start_reservations+0xa7/0xab [<ffffffff818bb3b8>] x86_64_start_kernel+0xf8/0x107 irq event stamp: 42037 hardirqs last enabled at (42037): [<ffffffff813a7b21>] _raw_spin_unlock_irqrestore+0x47/0x56 hardirqs last disabled at (42036): [<ffffffff813a72f4>] _raw_spin_lock_irqsave+0x2b/0x88 softirqs last enabled at (42000): [<ffffffffa0353ea6>] spin_unlock_bh+0xe/0x10 [ath9k] softirqs last disabled at (41998): [<ffffffff813a7463>] _raw_spin_lock_bh+0x18/0x6e other info that might help us debug this: 4 locks held by rmmod/3642: #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff8132c10d>] rtnl_lock+0x17/0x19 #1: (&wdev->mtx){+.+.+.}, at: [<ffffffffa01e53f2>] cfg80211_netdev_notifier_call+0x28d/0x46d [cfg80211] #2: (&ifmgd->mtx){+.+.+.}, at: [<ffffffffa0260834>] ieee80211_mgd_deauth+0x3f/0x17e [mac80211] #3: (&local->sta_mtx){+.+.+.}, at: [<ffffffffa025a381>] sta_info_destroy_addr+0x2b/0x5e [mac80211] stack backtrace: Pid: 3642, comm: rmmod Not tainted 2.6.33-wl #12 Call Trace: [<ffffffff81074469>] valid_state+0x178/0x18b [<ffffffff81014f94>] ? save_stack_trace+0x2f/0x4c [<ffffffff81074e08>] ? check_usage_backwards+0x0/0x88 [<ffffffff8107458f>] mark_lock+0x113/0x230 [<ffffffff810757f1>] __lock_acquire+0x36a/0xd35 [<ffffffff8101018d>] ? native_sched_clock+0x2d/0x5f [<ffffffffa03568c3>] ? ath_tx_node_cleanup+0x62/0x180 [ath9k] [<ffffffff81076289>] lock_acquire+0xcd/0xf1 [<ffffffffa03568c3>] ? ath_tx_node_cleanup+0x62/0x180 [ath9k] [<ffffffff810732eb>] ? trace_hardirqs_off+0xd/0xf [<ffffffff813a7193>] _raw_spin_lock+0x36/0x69 [<ffffffffa03568c3>] ? ath_tx_node_cleanup+0x62/0x180 [ath9k] [<ffffffffa03568c3>] ath_tx_node_cleanup+0x62/0x180 [ath9k] [<ffffffff810749ed>] ? trace_hardirqs_on+0xd/0xf [<ffffffffa0353950>] ath9k_sta_remove+0x22/0x26 [ath9k] [<ffffffffa025a08f>] __sta_info_destroy+0x1ad/0x38c [mac80211] [<ffffffffa025a394>] sta_info_destroy_addr+0x3e/0x5e [mac80211] [<ffffffffa02605d6>] ieee80211_set_disassoc+0x175/0x180 [mac80211] [<ffffffffa026084d>] ieee80211_mgd_deauth+0x58/0x17e [mac80211] [<ffffffff813a60c1>] ? __mutex_lock_common+0x37f/0x3a4 [<ffffffffa01e53f2>] ? cfg80211_netdev_notifier_call+0x28d/0x46d [cfg80211] [<ffffffffa026786e>] ieee80211_deauth+0x1e/0x20 [mac80211] [<ffffffffa01f47f9>] __cfg80211_mlme_deauth+0x130/0x13f [cfg80211] [<ffffffffa01e53f2>] ? cfg80211_netdev_notifier_call+0x28d/0x46d [cfg80211] [<ffffffff810732eb>] ? trace_hardirqs_off+0xd/0xf [<ffffffffa01f7eee>] __cfg80211_disconnect+0x111/0x189 [cfg80211] [<ffffffffa01e5433>] cfg80211_netdev_notifier_call+0x2ce/0x46d [cfg80211] [<ffffffff813aa9ea>] notifier_call_chain+0x37/0x63 [<ffffffff81068c98>] raw_notifier_call_chain+0x14/0x16 [<ffffffff81322e97>] call_netdevice_notifiers+0x1b/0x1d [<ffffffff8132386d>] dev_close+0x6a/0xa6 [<ffffffff8132395f>] rollback_registered_many+0xb6/0x2f4 [<ffffffff81323bb8>] unregister_netdevice_many+0x1b/0x66 [<ffffffffa026494f>] ieee80211_remove_interfaces+0xc5/0xd0 [mac80211] [<ffffffffa02580a2>] ieee80211_unregister_hw+0x47/0xe8 [mac80211] [<ffffffffa035290e>] ath9k_deinit_device+0x7a/0x9b [ath9k] [<ffffffffa035bc26>] ath_pci_remove+0x38/0x76 [ath9k] [<ffffffff8120940a>] pci_device_remove+0x2d/0x51 [<ffffffff8129d797>] __device_release_driver+0x7b/0xd1 [<ffffffff8129d885>] driver_detach+0x98/0xbe [<ffffffff8129ca7a>] bus_remove_driver+0x94/0xb7 [<ffffffff8129ddd6>] driver_unregister+0x6c/0x74 [<ffffffff812096d2>] pci_unregister_driver+0x46/0xad [<ffffffffa035bae1>] ath_pci_exit+0x15/0x17 [ath9k] [<ffffffffa035e1a2>] ath9k_exit+0xe/0x2f [ath9k] [<ffffffff8108050a>] sys_delete_module+0x1c7/0x236 [<ffffffff813a7df5>] ? retint_swapgs+0x13/0x1b [<ffffffff810749b5>] ? trace_hardirqs_on_caller+0x119/0x144 [<ffffffff8109b9f6>] ? audit_syscall_entry+0x11e/0x14a [<ffffffff81009bb2>] system_call_fastpath+0x16/0x1b wlan1: deauthenticating from 00:23:cd:e1:f9:b2 by local choice (reason=3) PM: Removing info for No Bus:wlan1 cfg80211: Calling CRDA to update world regulatory domain PM: Removing info for No Bus:rfkill2 PM: Removing info for No Bus:phy1 ath9k 0000:16:00.0: PCI INT A disabled Signed-off-by:
Ming Lei <tom.leiming@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Ping Cheng authored
commit 232f5693 upstream. Call wacom_query_tablet_data() from wacom_resume() so the device will be switched to Wacom mode upon resume. Devices that require this are: regular tablets and two finger touch devices. Signed-off-by:
Ping Cheng <pingc@wacom.com> Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
-
Don Skidmore authored
commit 74757d49 upstream. Signed-off-by:
Don Skidmore <donald.c.skidmore@intel.com> Acked-by:
Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Bruce Allan authored
commit 9e135a2e upstream. This new PCI device ID is for a new combination of MAC and PHY both of which already have supporting code in the driver, just not yet in this combination. During validation of the device, an intermittent issue was discovered with waking it from a suspended state which can be resolved with the pre-existing workaround to disable gigabit speed prior to suspending. Signed-off-by:
Bruce Allan <bruce.w.allan@intel.com> Signed-off-by:
-
Kees Cook authored
commit 0e1a6ef2 upstream. Currently the mmap_min_addr value can only be bypassed during mmap when the task has CAP_SYS_RAWIO. However, the mmap_min_addr sysctl value itself can be adjusted to 0 if euid == 0, allowing a bypass without CAP_SYS_RAWIO. This patch adds a check for the capability before allowing mmap_min_addr to be changed. Signed-off-by:
Kees Cook <kees.cook@canonical.com> Acked-by:
Serge Hallyn <serue@us.ibm.com> Signed-off-by:
James Morris <jmorris@namei.org> Signed-off-by:
-
David S. Miller authored
[ Upstream commit 8a4fd1e4 ] If we do something like try to print to the OF console from an NMI while we're already in OpenFirmware, we'll deadlock on the spinlock. Use a raw spinlock and disable NMIs when we take it. Signed-off-by:
-
Peter Zijlstra authored
commit 933b0618 upstream. A UP machine has 1 active cpu, not having the boot-cpu in the active map when starting the scheduler confuses things. Signed-off-by:
-
Alexander Duyck authored
commit 7a0deb6b upstream. This patch adds support for the 82576NS Serdes adapter to the existing pci quirk for 82576 parts. Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by:
-
Srinivas authored
commit 7ec4ad01 upstream. This is support for Adaptec ASC-1045/1405 SAS/SATA HBA on mvsas, which is based on Marvell 88SE6440 chipset. Signed-off-by:
Srinivas <satyasrinivasp@hcl.in> Cc: Andy Yan <ayan@marvell.com> Signed-off-by:
-
Suresh Siddha authored
commit 681ee44d upstream We need to fall back from logical-flat APIC mode to physical-flat mode when we have more than 8 CPUs. However, in the presence of CPU hotplug(with bios listing not enabled but possible cpus as disabled cpus in MADT), we have to consider the number of possible CPUs rather than the number of current CPUs; otherwise we may cross the 8-CPU boundary when CPUs are added later. 32bit apic code can use more cleanups (like the removal of vendor checks in 32bit default_setup_apic_routing()) and more unifications with 64bit code. Yinghai has some patches in works already. This patch addresses the boot issue that is reported in the virtualization guest context. Signed-off-by:
Shaohui Zheng <shaohui.zheng@intel.com> Reviewed-by:
Yinghai Lu <yinghai@kernel.org> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Thomas Gleixner authored
commit 41d2e494 upstream. The hrtimer_interrupt hang logic adjusts min_delta_ns based on the execution time of the hrtimer callbacks. This is error-prone for virtual machines, where a guest vcpu can be scheduled out during the execution of the callbacks (and the callbacks themselves can do operations that translate to blocking operations in the hypervisor), which in can lead to large min_delta_ns rendering the system unusable. Replace the current heuristics with something more reliable. Allow the interrupt code to try 3 times to catch up with the lost time. If that fails use the total time spent in the interrupt handler to defer the next timer interrupt so the system can catch up with other things which got delayed. Limit that deferment to 100ms. The retry events and the maximum time spent in the interrupt handler are recorded and exposed via /proc/timer_list Inspired by a patch from Marcelo. Reported-by:
Michael Tokarev <mjt@tls.msk.ru> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Tested-by:
Marcelo Tosatti <mtosatti@redhat.com> Cc: kvm@vger.kernel.org Cc: Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by:
-
Francesco Lavra authored
commit 19f48cb1 upstream. this patch fixes a memory leak which occurs when an em28xx card with DVB extension is unplugged or its DVB extension driver is unloaded. In dvb_fini(), dev->dvb must be freed before being set to NULL, as is done in dvb_init() in case of error. Note that this bug is also present in the latest stable kernel release. Signed-off-by:
Francesco Lavra <francescolavra@interfree.it> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
