summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915: fix tiling limits for i915 class hw v2Daniel Vetter2010-05-123-14/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit c36a2a6de59e4a141a68b7575de837d3b0bd96b3 upstream. Current code is definitely crap: Largest pitch allowed spills into the TILING_Y bit of the fence registers ... :( I've rewritten the limits check under the assumption that 3rd gen hw has a 3d pitch limit of 8kb (like 2nd gen). This is supported by an otherwise totally misleading XXX comment. This bug mostly resulted in tiling-corrupted pixmaps because the kernel allowed too wide buffers to be tiled. Bug brought to the light by the xf86-video-intel 2.11 release because that unconditionally enabled tiling for pixmaps, relying on the kernel to check things. Tiling for the framebuffer was not affected because the ddx does some additional checks there ensure the buffer is within hw-limits. v2: Instead of computing the value that would be written into the hw fence registers and then checking the limits simply check whether the stride is above the 8kb limit. To better document the hw, add some WARN_ONs in i915_write_fence_reg like I've done for the i830 case (using the right limits). Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=27449 Tested-by: Alexander Lam <lambchop468@gmail.com> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* drm/i915: Add initial bits for VGA modesetting bringup on Sandybridge.Eric Anholt2010-05-1211-56/+87
| | | | | | | | | | | | commit bad720ff3e8e47a04bd88d9bbc8317e7d7e049d3 upstream. [needed for stable as it's just a bunch of macros that other drm patches need, it changes no code functionality besides adding support for a new device type. - gregkh] Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* p54usb: Add usbid for Corega CG-WLUSB2GT.Shimada Hirofumi2010-05-121-0/+1
| | | | | | | | | | | commit 15a69a81731d337a3d9db51692ff8704c1114f43 upstream. Signed-off-by: Shimada Hirofumi <hirofumi@flycat.org> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> Cc: maximilian attems <max@stro.at> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: EHCI: defer reclamation of siTDsAlan Stern2010-05-124-11/+35
| | | | | | | | | | | | | | | | | | commit 0e5f231bc16ff9910882fa5b9d64d80e7691cfab upstream. This patch (as1369) fixes a problem in ehci-hcd. Some controllers occasionally run into trouble when the driver reclaims siTDs too quickly. This can happen while streaming audio; it causes the controller to crash. The patch changes siTD reclamation to work the same way as iTD reclamation: Completed siTDs are stored on a list and not reused until at least one frame has passed. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Nate Case <ncase@xes-inc.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Linux 2.6.33.3v2.6.33.3Greg Kroah-Hartman2010-04-261-1/+1
|
* r8169: clean up my printk uglynessNeil Horman2010-04-261-2/+2
| | | | | | | | | | | | | | | commit 93f4d91d879acfcb0ba9c2725e3133fcff2dfd1e upstream. Fix formatting on r8169 printk Brandon Philips noted that I had a spacing issue in my printk for the last r8169 patch that made it quite ugly. Fix that up and add the PFX macro to it as well so it looks like the other r8169 printks Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* x86/gart: Disable GART explicitly before initializationJoerg Roedel2010-04-262-1/+17
| | | | | | | | | | | | | | commit 4b83873d3da0704987cb116833818ed96214ee29 upstream. If we boot into a crash-kernel the gart might still be enabled and its caches might be dirty. This can result in undefined behavior later. Fix it by explicitly disabling the gart hardware before initialization and flushing the caches after enablement. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* KVM: x86: Fix TSS size check for 16-bit tasksJan Kiszka2010-04-261-1/+5
| | | | | | | | | | | | (Cherry-picked from commit e8861cfe2c75bdce36655b64d7ce02c2b31b604d) A 16-bit TSS is only 44 bytes long. So make sure to test for the correct size on task switch. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* KVM: Increase NR_IOBUS_DEVS limit to 200Sridhar Samudrala2010-04-261-1/+1
| | | | | | | | | | | | | | (Cherry-picked from commit e80e2a60ff7914dae691345a976c80bbbff3ec74) This patch increases the current hardcoded limit of NR_IOBUS_DEVS from 6 to 200. We are hitting this limit when creating a guest with more than 1 virtio-net device using vhost-net backend. Each virtio-net device requires 2 such devices to service notifications from rx/tx queues. Signed-off-by: Sridhar Samudrala <sri@us.ibm.com> Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* KVM: fix the handling of dirty bitmaps to avoid overflowsTakuya Yoshikawa2010-04-265-13/+23
| | | | | | | | | | | | | | | | | (Cherry-picked from commit 87bf6e7de1134f48681fd2ce4b7c1ec45458cb6d) Int is not long enough to store the size of a dirty bitmap. This patch fixes this problem with the introduction of a wrapper function to calculate the sizes of dirty bitmaps. Note: in mark_page_dirty(), we have to consider the fact that __set_bit() takes the offset as int, not long. Signed-off-by: Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* KVM: MMU: fix kvm_mmu_zap_page() and its calling pathXiao Guangrong2010-04-261-4/+7
| | | | | | | | | | | | | | | | (Cherry-picked from commit 77662e0028c7c63e34257fda03ff9625c59d939d) This patch fix: - calculate zapped page number properly in mmu_zap_unsync_children() - calculate freeed page number properly kvm_mmu_change_mmu_pages() - if zapped children page it shoud restart hlist walking KVM-Stable-Tag. Signed-off-by: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* KVM: VMX: Save/restore rflags.vm correctly in real modeAvi Kivity2010-04-261-9/+15
| | | | | | | | | | | | | | | | | | | | | | (Cherry-picked from commit 78ac8b47c566dd6177a3b9b291b756ccb70670b7) Currently we set eflags.vm unconditionally when entering real mode emulation through virtual-8086 mode, and clear it unconditionally when we enter protected mode. The means that the following sequence KVM_SET_REGS (rflags.vm=1) KVM_SET_SREGS (cr0.pe=1) Ends up with rflags.vm clear due to KVM_SET_SREGS triggering enter_pmode(). Fix by shadowing rflags.vm (and rflags.iopl) correctly while in real mode: reads and writes to those bits access a shadow register instead of the actual register. Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* KVM: allow bit 10 to be cleared in MSR_IA32_MC4_CTLAndre Przywara2010-04-261-2/+6
| | | | | | | | | | | | | | | | | | (Cherry-picked from commit 114be429c8cd44e57f312af2bbd6734e5a185b0d) There is a quirk for AMD K8 CPUs in many Linux kernels (see arch/x86/kernel/cpu/mcheck/mce.c:__mcheck_cpu_apply_quirks()) that clears bit 10 in that MCE related MSR. KVM can only cope with all zeros or all ones, so it will inject a #GP into the guest, which will let it panic. So lets add a quirk to the quirk and ignore this single cleared bit. This fixes -cpu kvm64 on all machines and -cpu host on K8 machines with some guest Linux kernels. Signed-off-by: Andre Przywara <andre.przywara@amd.com> Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* KVM: Don't spam kernel log when injecting exceptions due to bad cr writesAvi Kivity2010-04-261-27/+0
| | | | | | | | | | (Cherry-picked from commit d6a23895aa82353788a1cc5a1d9a1c963465463e) These are guest-triggerable. Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* KVM: SVM: Fix memory leaks that happen when svm_create_vcpu() failsTakuya Yoshikawa2010-04-261-10/+15
| | | | | | | | | | | | (Cherry-picked from commit b7af40433870aa0636932ad39b0c48a0cb319057) svm_create_vcpu() does not free the pages allocated during the creation when it fails to complete the allocations. This patch fixes it. Signed-off-by: Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp> Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* KVM: VMX: Update instruction length on intercepted BPJan Kiszka2010-04-261-0/+13
| | | | | | | | | | | | | | | (Cherry-picked from commit c573cd22939e54fc1b8e672054a505048987a7cb) We intercept #BP while in guest debugging mode. As VM exits due to intercepted exceptions do not necessarily come with valid idt_vectoring, we have to update event_exit_inst_len explicitly in such cases. At least in the absence of migration, this ensures that re-injections of #BP will find and use the correct instruction length. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* sched: Use proper type in sched_getaffinity()KOSAKI Motohiro2010-04-261-1/+1
| | | | | | | | | | | | | | | | | | | | | commit 8bc037fb89bb3104b9ae290d18c877624cd7d9cc upstream. Using the proper type fixes the following compiler warning: kernel/sched.c:4850: warning: comparison of distinct pointer types lacks a cast Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: torvalds@linux-foundation.org Cc: travis@sgi.com Cc: peterz@infradead.org Cc: drepper@redhat.com Cc: rja@sgi.com Cc: sharyath@in.ibm.com Cc: steiner@sgi.com LKML-Reference: <20100317090046.4C79.A69D9226@jp.fujitsu.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* ext4: fix async i/o writes beyond 4GB to a sparse fileEric Sandeen2010-04-263-5/+5
| | | | | | | | | | | | | | | | | | | | commit a1de02dccf906faba2ee2d99cac56799bda3b96a upstream. The "offset" member in ext4_io_end holds bytes, not blocks, so ext4_lblk_t is wrong - and too small (u32). This caused the async i/o writes to sparse files beyond 4GB to fail when they wrapped around to 0. Also fix up the type of arguments to ext4_convert_unwritten_extents(), it gets ssize_t from ext4_end_aio_dio_nolock() and ext4_ext_direct_IO(). Reported-by: Giel de Nijs <giel@vectorwise.com> Signed-off-by: Eric Sandeen <sandeen@redhat.com> Cc: maximilian attems <max@stro.at> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* powerpc: Fix SMP build with disabled CPU hotplugging.Adam Lackorzynski2010-04-261-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | | commit 5b72d74ce2fccca2a301de60f31b16ddf5c93984 upstream. Compiling 2.6.33 with SMP enabled and HOTPLUG_CPU disabled gives me the following link errors: LD init/built-in.o LD .tmp_vmlinux1 arch/powerpc/platforms/built-in.o: In function `.smp_xics_setup_cpu': smp.c:(.devinit.text+0x88): undefined reference to `.set_cpu_current_state' smp.c:(.devinit.text+0x94): undefined reference to `.set_default_offline_state' arch/powerpc/platforms/built-in.o: In function `.smp_pSeries_kick_cpu': smp.c:(.devinit.text+0x13c): undefined reference to `.set_preferred_offline_state' smp.c:(.devinit.text+0x148): undefined reference to `.get_cpu_current_state' smp.c:(.devinit.text+0x1a8): undefined reference to `.get_cpu_current_state' make: *** [.tmp_vmlinux1] Error 1 The following change fixes that for me and seems to work as expected. Signed-off-by: Adam Lackorzynski <adam@os.inf.tu-dresden.de> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* md: deal with merge_bvec_fn in component devices better.NeilBrown2010-04-264-30/+43
| | | | | | | | | | | | | | | | | | | | commit 627a2d3c29427637f4c5d31ccc7fcbd8d312cd71 upstream. If a component device has a merge_bvec_fn then as we never call it we must ensure we never need to. Currently this is done by setting max_sector to 1 PAGE, however this does not stop a bio being created with several sub-page iovecs that would violate the merge_bvec_fn. So instead set max_phys_segments to 1 and set the segment boundary to the same as a page boundary to ensure there is only ever one single-page segment of IO requested at a time. This can particularly be an issue when 'xen' is used as it is known to submit multiple small buffers in a single bio. Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* module: fix __module_ref_addr()Mathieu Desnoyers2010-04-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The __module_ref_addr() problem disappears in 2.6.34-rc kernels because these percpu accesses were re-factored. __module_ref_addr() should use per_cpu_ptr() to obfuscate the pointer (RELOC_HIDE is needed for per cpu pointers). This non-standard per-cpu pointer use has been introduced by commit 720eba31f47aeade8ec130ca7f4353223c49170f It causes a NULL pointer exception on some configurations when CONFIG_TRACING is enabled on 2.6.33. This patch fixes the problem (acknowledged by Randy who reported the bug). It did not appear to hurt previously because most of the accesses were done through local_inc, which probably obfuscated the access enough that no compiler optimizations were done. But with local_read() done when CONFIG_TRACING is active, this becomes a problem. Non-CONFIG_TRACING is probably affected as well (module.c contains local_set and local_read that use __module_ref_addr()), but I guess nobody noticed because we've been lucky enough that the compiler did not generate the inappropriate optimization pattern there. This patch should be queued for the 2.6.29.x through 2.6.33.x stable branches. (tested on 2.6.33.1 x86_64) Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Tested-by: Randy Dunlap <randy.dunlap@oracle.com> CC: Eric Dumazet <dada1@cosmosbay.com> CC: Rusty Russell <rusty@rustcorp.com.au> CC: Peter Zijlstra <a.p.zijlstra@chello.nl> CC: Tejun Heo <tj@kernel.org> CC: Ingo Molnar <mingo@elte.hu> CC: Andrew Morton <akpm@linux-foundation.org> CC: Linus Torvalds <torvalds@linux-foundation.org> CC: Greg Kroah-Hartman <gregkh@suse.de> CC: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* lockdep: fix incorrect percpu usageMathieu Desnoyers2010-04-261-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The mainline kernel as of 2.6.34-rc5 is not affected by this problem because commit 10fad5e46f6c7bdfb01b1a012380a38e3c6ab346 fixed it by refactoring. lockdep fix incorrect percpu usage Should use per_cpu_ptr() to obfuscate the per cpu pointers (RELOC_HIDE is needed for per cpu pointers). git blame points to commit: lockdep.c: commit 8e18257d29238311e82085152741f0c3aa18b74d But it's really just moving the code around. But it's enough to say that the problems appeared before Jul 19 01:48:54 2007, which brings us back to 2.6.23. It should be applied to stable 2.6.23.x to 2.6.33.x (or whichever of these stable branches are still maintained). (tested on 2.6.33.1 x86_64) Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> CC: Randy Dunlap <randy.dunlap@oracle.com> CC: Eric Dumazet <dada1@cosmosbay.com> CC: Rusty Russell <rusty@rustcorp.com.au> CC: Peter Zijlstra <a.p.zijlstra@chello.nl> CC: Tejun Heo <tj@kernel.org> CC: Ingo Molnar <mingo@elte.hu> CC: Andrew Morton <akpm@linux-foundation.org> CC: Linus Torvalds <torvalds@linux-foundation.org> CC: Greg Kroah-Hartman <gregkh@suse.de> CC: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* modules: fix incorrect percpu usageMathieu Desnoyers2010-04-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mainline does not need this fix, as commit 259354deaaf03d49a02dbb9975d6ec2a54675672 fixed the problem by refactoring. Should use per_cpu_ptr() to obfuscate the per cpu pointers (RELOC_HIDE is needed for per cpu pointers). Introduced by commit: module.c: commit 6b588c18f8dacfa6d7957c33c5ff832096e752d3 This patch should be queued for the stable branch, for kernels 2.6.29.x to 2.6.33.x. (tested on 2.6.33.1 x86_64) Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> CC: Randy Dunlap <randy.dunlap@oracle.com> CC: Eric Dumazet <dada1@cosmosbay.com> CC: Rusty Russell <rusty@rustcorp.com.au> CC: Peter Zijlstra <a.p.zijlstra@chello.nl> CC: Tejun Heo <tj@kernel.org> CC: Ingo Molnar <mingo@elte.hu> CC: Andrew Morton <akpm@linux-foundation.org> CC: Linus Torvalds <torvalds@linux-foundation.org> CC: Greg Kroah-Hartman <gregkh@suse.de> CC: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* ACPI: EC: Limit burst to 64 bitsAlexey Starikovskiy2010-04-261-6/+11
| | | | | | | | | | | | | | | | | | | | commit 2060c44576c79086ff24718878d7edaa7384a985 upstream. access_bit_width field is u8 in ACPICA, thus 256 value written to it becomes 0, causing divide by zero later. Proper fix would be to remove access_bit_width at all, just because we already have access_byte_width, which is access_bit_width / 8. Limit access width to 64 bit for now. https://bugzilla.kernel.org/show_bug.cgi?id=15749 fixes regression caused by the fix for: https://bugzilla.kernel.org/show_bug.cgi?id=14667 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* ACPI: EC: Allow multibyte access to ECAlexey Starikovskiy2010-04-262-26/+21
| | | | | | | | | | | | | | commit dadf28a10c3eb29421837a2e413ab869ebd upstream http://bugzilla.kernel.org/show_bug.cgi?id=14667 [bwh: Backport to 2.6.32; same applies to 2.6.33] Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* xfs: check for more work before sleeping in xfssyncdDave Chinner2010-04-261-3/+3
| | | | | | | | | | | | | | | | | | | commit 20f6b2c785cf187445f126321638ab8ba7aa7494 upstream. xfssyncd processes a queue of work by detaching the queue and then iterating over all the work items. It then sleeps for a time period or until new work comes in. If new work is queued while xfssyncd is actively processing the detached work queue, it will not process that new work until after a sleep timeout or the next work event queued wakes it. Fix this by checking the work queue again before going to sleep. Signed-off-by: Dave Chinner <david@fromorbit.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Alex Elder <aelder@sgi.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* xfs: fix locking for inode cache radix tree tag updatesChristoph Hellwig2010-04-262-8/+15
| | | | | | | | | | | | | | | | | | | commit f1f724e4b523d444c5a598d74505aefa3d6844d2 upstream. The radix-tree code requires it's users to serialize tag updates against other updates to the tree. While XFS protects tag updates against each other it does not serialize them against updates of the tree contents, which can lead to tag corruption. Fix the inode cache to always take pag_ici_lock in exclusive mode when updating radix tree tags. Signed-off-by: Christoph Hellwig <hch@lst.de> Reported-by: Patrick Schreurs <patrick@news-service.com> Tested-by: Patrick Schreurs <patrick@news-service.com> Signed-off-by: Alex Elder <aelder@sgi.com> Cc: Dave Chinner <david@fromorbit.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* xfs: Non-blocking inode locking in IO completionDave Chinner2010-04-261-37/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 77d7a0c2eeb285c9069e15396703d0cb9690ac50 upstream. The introduction of barriers to loop devices has created a new IO order completion dependency that XFS does not handle. The loop device implements barriers using fsync and so turns a log IO in the XFS filesystem on the loop device into a data IO in the backing filesystem. That is, the completion of log IOs in the loop filesystem are now dependent on completion of data IO in the backing filesystem. This can cause deadlocks when a flush daemon issues a log force with an inode locked because the IO completion of IO on the inode is blocked by the inode lock. This in turn prevents further data IO completion from occuring on all XFS filesystems on that CPU (due to the shared nature of the completion queues). This then prevents the log IO from completing because the log is waiting for data IO completion as well. The fix for this new completion order dependency issue is to make the IO completion inode locking non-blocking. If the inode lock can't be grabbed, simply requeue the IO completion back to the work queue so that it can be processed later. This prevents the completion queue from being blocked and allows data IO completion on other inodes to proceed, hence avoiding completion order dependent deadlocks. Signed-off-by: Dave Chinner <david@fromorbit.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Alex Elder <aelder@sgi.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* perf_events, x86: Implement Intel Westmere/Nehalem-EX supportPeter Zijlstra2010-04-261-1/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | original patch commit ids: 452a339a976e7f782c786eb3f73080401e2fa3a6 and 134fbadf028a5977a1b06b0253d3ee33e6f0c642 perf_events, x86: Implement Intel Westmere support The new Intel documentation includes Westmere arch specific event maps that are significantly different from the Nehalem ones. Add support for this generation. Found the CPUID model numbers on wikipedia. Also ammend some Nehalem constraints, spotted those when looking for the differences between Nehalem and Westmere. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Stephane Eranian <eranian@google.com> LKML-Reference: <20100127221122.151865645@chello.nl> Signed-off-by: Ingo Molnar <mingo@elte.hu> perf, x86: Enable Nehalem-EX support According to Intel Software Devel Manual Volume 3B, the Nehalem-EX PMU is just like regular Nehalem (except for the uncore support, which is completely different). Signed-off-by: Vince Weaver <vweaver1@eecs.utk.edu> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Lin Ming <ming.m.lin@intel.com> LKML-Reference: <alpine.DEB.2.00.1004060956580.1417@cl320.eecs.utk.edu> Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: Youquan Song <youquan.song@linux.intel.com>
* e1000e: stop cleaning when we reach tx_ring->next_to_useTerry Loftin2010-04-261-0/+2
| | | | | | | | | | | | | | | | commit dac876193cd79ced36d0462749ea47c05844fb49 upstream. Tx ring buffers after tx_ring->next_to_use are volatile and could change, possibly causing a crash. Stop cleaning when we hit tx_ring->next_to_use. Signed-off-by: Terry Loftin <terry.loftin@hp.com> Acked-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> Cc: Matthew Burgess <matthew@linuxfromscratch.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* iwlwifi: fix scan raceReinette Chatre2010-04-261-15/+12
| | | | | | | | | | | | | | | | | | | | | | | commit bbcbb9ef9735c67da303d30bd6beb9e699f0f508 upstream. There is a problem if an "internal short scan" is in progress when a mac80211 requested scan arrives. If this new scan request arrives within the "next_scan_jiffies" period then driver will immediately return success and complete the scan. The problem here is that the scan has not been fully initialized at this time (is_internal_short_scan is still set to true because of the currently running scan), which results in the scan completion never to be sent to mac80211. At this time also, evan though the internal short scan is still running the state (is_internal_short_scan) will be set to false, so when the internal scan does complete then mac80211 will receive a scan completion. Fix this by checking right away if a scan is in progress when a scan request arrives from mac80211. Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Cc: maximilian attems <max@stro.at> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* iwlwifi: clear all tx queues when firmware readyWey-Yi Guy2010-04-262-0/+4
| | | | | | | | | | | | | commit dff010ac8e57e43669518a14c0e945dfeb80c2a7 upstream. Reset and clear all the tx queues when finished downloading runtime uCode and ready to go into operation mode. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Cc: maximilian attems <max@stro.at> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: cdc-acm: Fix stupid NULL pointer in resume()Oliver Neukum2010-04-261-1/+1
| | | | | | | | | | | commit f0730924e9e32bb8935c60040a26d94179355088 upstream. Stupid logic bug passing a just nulled pointer Signed-off-by: Oliver Neukum <neukum@b1-systems.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: cdc-acm: Update to new autopm APIOliver Neukum2010-04-262-22/+22
| | | | | | | | | | | | commit 97d35f95552c9a0ee4777a7f04431a9fd1260478 upstream. Update cdc-acm to the async methods eliminating the workqueue [This fixes a reported lockup for the cdc-acm driver - gregkh] Signed-off-by: Oliver Neukum <oliver@neukum.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* ecryptfs: fix error code for missing xattrs in lower fsChristian Pulvermacher2010-04-261-4/+4
| | | | | | | | | | | | | | | commit cfce08c6bdfb20ade979284e55001ca1f100ed51 upstream. If the lower file system driver has extended attributes disabled, ecryptfs' own access functions return -ENOSYS instead of -EOPNOTSUPP. This breaks execution of programs in the ecryptfs mount, since the kernel expects the latter error when checking for security capabilities in xattrs. Signed-off-by: Christian Pulvermacher <pulvermacher@gmx.de> Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* eCryptfs: Decrypt symlink target for stat sizeTyler Hicks2010-04-261-48/+52
| | | | | | | | | | | | | | | | | | commit 3a60a1686f0d51c99bd0df8ac93050fb6dfce647 upstream. Create a getattr handler for eCryptfs symlinks that is capable of reading the lower target and decrypting its path. Prior to this patch, a stat's st_size field would represent the strlen of the encrypted path, while readlink() would return the strlen of the decrypted path. This could lead to confusion in some userspace applications, since the two values should be equal. https://bugs.launchpad.net/bugs/524919 Reported-by: Loïc Minier <loic.minier@canonical.com> Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* ecryptfs: fix use with tmpfs by removing d_drop from ecryptfs_destroy_inodeJeff Mahoney2010-04-261-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 133b8f9d632cc23715c6d72d1c5ac449e054a12a upstream. Since tmpfs has no persistent storage, it pins all its dentries in memory so they have d_count=1 when other file systems would have d_count=0. ->lookup is only used to create new dentries. If the caller doesn't instantiate it, it's freed immediately at dput(). ->readdir reads directly from the dcache and depends on the dentries being hashed. When an ecryptfs mount is mounted, it associates the lower file and dentry with the ecryptfs files as they're accessed. When it's umounted and destroys all the in-memory ecryptfs inodes, it fput's the lower_files and d_drop's the lower_dentries. Commit 4981e081 added this and a d_delete in 2008 and several months later commit caeeeecf removed the d_delete. I believe the d_drop() needs to be removed as well. The d_drop effectively hides any file that has been accessed via ecryptfs from the underlying tmpfs since it depends on it being hashed for it to be accessible. I've removed the d_drop on my development node and see no ill effects with basic testing on both tmpfs and persistent storage. As a side effect, after ecryptfs d_drops the dentries on tmpfs, tmpfs BUGs on umount. This is due to the dentries being unhashed. tmpfs->kill_sb is kill_litter_super which calls d_genocide to drop the reference pinning the dentry. It skips unhashed and negative dentries, but shrink_dcache_for_umount_subtree doesn't. Since those dentries still have an elevated d_count, we get a BUG(). This patch removes the d_drop call and fixes both issues. This issue was reported at: https://bugzilla.novell.com/show_bug.cgi?id=567887 Reported-by: Árpád Bíró <biroa@demasz.hu> Signed-off-by: Jeff Mahoney <jeffm@suse.com> Cc: Dustin Kirkland <kirkland@canonical.com> Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* ALSA: hda - Add position_fix quirk for Biostar moboTakashi Iwai2010-04-261-0/+1
| | | | | | | | | | | | | | | | | | | | commit 8815cd030fdd73932a791d1f06194c8db807cde7 upstream. The Biostar mobo seems to give a wrong DMA position, resulting in stuttering or skipping sounds on 2.6.34. Since the commit 7b3a177b0d4f92b3431b8dca777313a07533a710, "ALSA: pcm_lib: fix "something must be really wrong" condition", makes the position check more strictly, the DMA position problem is revealed more clearly now. The fix is to use only LPIB for obtaining the position, i.e. passing position_fix=1. This patch adds a static quirk to achieve it as default. Reported-by: Frank Griffin <ftg@roadrunner.com> Cc: Eric Piel <Eric.Piel@tremplin-utc.net> Signed-off-by: Takashi Iwai <tiwai@suse.de> Cc: maximilian attems <max@stro.at> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* b43: fall back gracefully to PIO mode after fatal DMA errorsLinus Torvalds2010-04-263-7/+31
| | | | | | | | | | | | | | | | | | | | | | commit 9e3bd9190800e8209b4a3e1d724c35f0738dcad2 upstream. This makes the b43 driver just automatically fall back to PIO mode when DMA doesn't work. The driver already told the user to do it, so rather than have the user reload the module with a new flag, just make the driver do it automatically. We keep the message as an indication that something is wrong, but now just automatically fall back to the hopefully working PIO case. (Some post-2.6.33 merge fixups by Larry Finger <Larry.Finger@lwfinger.net> and yours truly... -- JWL) Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> Cc: maximilian attems <max@stro.at> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* b43: Allow PIO mode to be selected at module loadLarry Finger2010-04-266-75/+8
| | | | | | | | | | | | | | | | | | | | commit b02914af4d7020828ce921a572589dd793517c09 upstream. If userencounter the "Fatal DMA Problem" with a BCM43XX device, and still wish to use b43 as the driver, their only option is to rebuild the kernel with CONFIG_B43_FORCE_PIO. This patch removes this option and allows PIO mode to be selected with a load-time parameter for the module. Note that the configuration variable CONFIG_B43_PIO is also removed. Once the DMA problem with the BCM4312 devices is solved, this patch will likely be reverted. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Tested-by: John Daiker <daikerjohn@gmail.com> Cc: maximilian attems <max@stro.at> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* i2c-i801: Add Intel Cougar Point device IDsSeth Heasley2010-04-263-4/+9
| | | | | | | | | | | | commit 393764340beb595c1ad7dd2d2243c2b6551aaa71 upstream. Add the Intel Cougar Point (PCH) SMBus controller device IDs. Signed-off-by: Seth Heasley <seth.heasley@intel.com> Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: maximilian attems <max@stro.at> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* ahci: AHCI and RAID mode SATA patch for Intel Cougar Point DeviceIDsSeth Heasley2010-04-261-0/+6
| | | | | | | | | | commit 5623cab83ea61e0420f2064216d83eab067a24c6 upstream. Signed-off-by: Seth Heasley <seth.heasley@intel.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Cc: maximilian attems <max@stro.at> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* ata_piix: IDE Mode SATA patch for Intel Cougar Point DeviceIDsSeth Heasley2010-04-261-0/+8
| | | | | | | | | | commit 88e8201e67aace3d86de9e75122ea525f0e7248e upstream. Signed-off-by: Seth Heasley <seth.heasley@intel.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Cc: maximilian attems <max@stro.at> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* ALSA: hda - enable snoop for Intel Cougar PointSeth Heasley2010-04-261-1/+5
| | | | | | | | | | | | | commit 32679f95cac3b1bdf27dce8b5273e06af186fd91 upstream. This patch enables snoop, eliminating static during playback. This patch supersedes the previous Cougar Point audio patch. Signed-off-by: Seth Heasley <seth.heasley@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Cc: maximilian attems <max@stro.at> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* ALSA: hda_intel: ALSA HD Audio patch for Intel Cougar Point DeviceIDsSeth Heasley2010-04-261-0/+3
| | | | | | | | | | | | commit d2f2fcd2541bae004db7f4798ffd9d2cb75ae817 upstream. This patch adds the Intel Cougar Point (PCH) HD Audio Controller DeviceIDs. Signed-off-by: Seth Heasley <seth.heasley@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Cc: maximilian attems <max@stro.at> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* x86/PCI: irq and pci_ids patch for Intel Cougar Point DeviceIDsSeth Heasley2010-04-262-0/+5
| | | | | | | | | | | | commit 93da6202264ce1256b04db8008a43882ae62d060 upstream. This patch adds the Intel Cougar Point (PCH) LPC and SMBus Controller DeviceIDs. Signed-off-by: Seth Heasley <seth.heasley@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: maximilian attems <max@stro.at> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* IPoIB: Fix TX queue lockup with mixed UD/CM trafficEli Cohen2010-04-261-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | commit f0dc117abdfa9a0e96c3d013d836460ef3cd08c7 upstream. The IPoIB UD QP reports send completions to priv->send_cq, which is usually left unarmed; it only gets armed when the number of outstanding send requests reaches the size of the TX queue. This arming is done only in the send path for the UD QP. However, when sending CM packets, the net queue may be stopped for the same reasons but no measures are taken to recover the UD path from a lockup. Consider this scenario: a host sends high rate of both CM and UD packets, with a TX queue length of N. If at some time the number of outstanding UD packets is more than N/2 and the overall outstanding packets is N-1, and CM sends a packet (making the number of outstanding sends equal N), the TX queue will be stopped. When all the CM packets complete, the number of outstanding packets will still be higher than N/2 so the TX queue will not be restarted. Fix this by calling ib_req_notify_cq() when the queue is stopped in the CM path. Signed-off-by: Eli Cohen <eli@mellanox.co.il> Signed-off-by: Roland Dreier <rolandd@cisco.com> Cc: maximilian attems <max@stro.at> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* PCI: kill off pci_register_set_vga_state() symbol export.Paul Mundt2010-04-261-1/+0
| | | | | | | | | | | | | | | commit ded1d8f29b4d315a2093cafc3ee17ac870a87972 upstream. When pci_register_set_vga_state() was made __init, the EXPORT_SYMBOL() was retained, which now leaves us with a section mismatch. Signed-off-by: Paul Mundt <lethal@linux-sh.org> Cc: Mike Travis <travis@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: maximilian attems <max@stro.at> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* pci: Update pci_set_vga_state() to call arch functionsMike Travis2010-04-262-1/+29
| | | | | | | | | | | | | | | | | | | | | | commit 95a8b6efc5d07103583f706c8a5889437d537939 upstream. Update pci_set_vga_state to call arch dependent functions to enable Legacy VGA I/O transactions to be redirected to correct target. [akpm@linux-foundation.org: make pci_register_set_vga_state() __init] Signed-off-by: Mike Travis <travis@sgi.com> LKML-Reference: <201002022238.o12McE1J018723@imap1.linux-foundation.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Robin Holt <holt@sgi.com> Cc: Jack Steiner <steiner@sgi.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: David Airlie <airlied@linux.ie> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: H. Peter Anvin <hpa@zytor.com> Cc: maximilian attems <max@stro.at> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* 9p: Skip check for mandatory locks when unlockingSachin Prabhu2010-04-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | commit f78233dd44a110c574fe760ad6f9c1e8741a0d00 upstream. While investigating a bug, I came across a possible bug in v9fs. The problem is similar to the one reported for NFS by ASANO Masahiro in http://lkml.org/lkml/2005/12/21/334. v9fs_file_lock() will skip locks on file which has mode set to 02666. This is a problem in cases where the mode of the file is changed after a process has obtained a lock on the file. Such a lock will be skipped during unlock and the machine will end up with a BUG in locks_remove_flock(). v9fs_file_lock() should skip the check for mandatory locks when unlocking a file. Signed-off-by: Sachin Prabhu <sprabhu@redhat.com> Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com> Cc: maximilian attems <max@stro.at> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
generated by cgit (git 2.34.1) at 2025-01-10 18:19:58 +0000