- 12 May, 2010 7 commits
-
-
Ian Dall authored
commit 9a6a1ecd upstream. Fix regression caused by commit 507e2fba ("w1: w1 temp calculation overflow fix") whereby negative temperatures for the DS18B20 are not converted properly. When the temperature exceeds 32767 milli-degrees the temperature overflows to -32768 millidegrees. These are both well within the -55 - +125 degree range for the sensor. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=12646Signed-of-by:
Ian Dall <ian@beware.dropbear.id.au> Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Tested-by:
Karsten Elfenbein <kelfe@gmx.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jeff Garzik authored
libata: ensure NCQ error result taskfile is fully initialized before returning it via qc->result_tf. commit a09bf4cd upstream. Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Tejun Heo authored
commit fa41efda upstream. blk_abort_request() expectes queue lock to be held by the caller. Grab it before calling the function. Lack of this synchronization led to infinite loop on corrupt q->timeout_list. Signed-off-by:
Tejun Heo <tj@kernel.org> Cc: Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
NeilBrown authored
commit 6e3b96ed upstream. Previous patch changes stripe and chunk_number to sector_t but mistakenly did not update all of the divisions to use sector_dev(). This patch changes all the those divisions (actually the '%' operator) to sector_div. Signed-off-by:
NeilBrown <neilb@suse.de> Tested-by:
Stefan Lippers-Hollmann <s.l-h@gmx.de> Signed-off-by:
-
NeilBrown authored
commit 35f2a591 upstream. With many large drives and small chunk sizes it is possible to create a RAID5 with more than 2^31 chunks. Make sure this works. Reported-by:
Brett King <king.br@gmail.com> Signed-off-by:
-
Shimada Hirofumi authored
commit 15a69a81 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:
-
Alan Stern authored
commit 0e5f231b 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:
-
- 26 Apr, 2010 33 commits
-
-
Greg Kroah-Hartman authored
-
Neil Horman authored
commit 93f4d91d 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:
-
Joerg Roedel authored
commit 4b83873d 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:
-
Jan Kiszka authored
(Cherry-picked from commit e8861cfe) 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:
-
Sridhar Samudrala authored
(Cherry-picked from commit e80e2a60) 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:
-
Takuya Yoshikawa authored
(Cherry-picked from commit 87bf6e7d) 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:
-
Xiao Guangrong authored
(Cherry-picked from commit 77662e00) 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:
-
Avi Kivity authored
(Cherry-picked from commit 78ac8b47) 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:
-
Andre Przywara authored
(Cherry-picked from commit 114be429) 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 authored
(Cherry-picked from commit d6a23895) These are guest-triggerable. Signed-off-by:
-
Takuya Yoshikawa authored
(Cherry-picked from commit b7af4043) 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:
-
KOSAKI Motohiro authored
commit 8bc037fb 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:
-
Kashyap, Desai authored
commit 9b53b392 upstream. Errata: Certain conditions on the scsi bus may casue the 53C1030 to incorrectly signal a SCSI_DATA_UNDERRUN to the host. Workaround 1: For an Errata on LSI53C1030 When the length of request data and transfer data are different with result of command (READ or VERIFY), DID_SOFT_ERROR is set. Workaround 2: For potential trouble on LSI53C1030. It is checked whether the length of request data is equal to the length of transfer and residual. MEDIUM_ERROR is set by incorrect data. Signed-off-by:
Kashyap Desai <kashyap.desai@lsi.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Kashyap, Desai authored
commit e39e145d upstream. Signed-off-by:
-
Or Gerlitz authored
commit c1ccaf24 upstream. After dma-mapping an SG list provided by the SCSI midlayer, iser has to make sure the mapped SG is "aligned for RDMA" in the sense that its possible to produce one mapping in the HCA IOMMU which represents the whole SG. Next, the mapped SG is formatted for registration with the HCA. This patch re-writes the logic that does the above, to make it clearer and simpler. It also fixes a bug in the being aligned for RDMA checks, where a "start" check wasn't done but rather only "end" check. [commit message in RH kernel tree: "Under heavy load, without the patch, the HCA can be programmed to write (corrupt) into pages/location which doesn't belong to the SG associated with the actual I/O and cause a kernel oops."] Signed-off-by:
Alexander Nezhinsky <alexandern@voltaire.com> Signed-off-by:
Or Gerlitz <ogerlitz@voltaire.com> Signed-off-by:
Roland Dreier <rolandd@cisco.com> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Matt Domsch authored
commit 31bde71c upstream. The tpm_tis driver already has a list of supported pnp_device_ids. This patch simply exports that list as a MODULE_DEVICE_TABLE() so that the module autoloader will discover and load the module at boottime. Signed-off-by:
Matt Domsch <Matt_Domsch@dell.com> Acked-by:
Rajiv Andrade <srajiv@linux.vnet.ibm.com> Signed-off-by:
James Morris <jmorris@namei.org> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Eric Sandeen authored
commit a1de02dc 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:
-
Eric Sandeen authored
commit c8afb446 upstream. Creating many small files in rapid succession on a small filesystem can lead to spurious ENOSPC; on a 104MB filesystem: for i in `seq 1 22500`; do echo -n > $SCRATCH_MNT/$i echo XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > $SCRATCH_MNT/$i done leads to ENOSPC even though after a sync, 40% of the fs is free again. This is because we reserve worst-case metadata for delalloc writes, and when data is allocated that worst-case reservation is not usually needed. When freespace is low, kicking off an async writeback will start converting that worst-case space usage into something more realistic, almost always freeing up space to continue. This resolves the testcase for me, and survives all 4 generic ENOSPC tests in xfstests. We'll still need a hard synchronous sync to squeeze out the last bit, but this fixes things up to a large degree. Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Eric Sandeen authored
commit 17bd55d0 upstream. ext4, at least, would like to start pushing on writeback if it starts to get close to ENOSPC when reserving worst-case blocks for delalloc writes. Writing out delalloc data will convert those worst-case predictions into usually smaller actual usage, freeing up space before we hit ENOSPC based on this speculation. Thanks to Jens for the suggestion for the helper function, & the naming help. I've made the helper return status on whether writeback was started even though I don't plan to use it in the ext4 patch; it seems like it would be potentially useful to test this in some cases. Signed-off-by:
Jan Kara <jack@suse.cz> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Johannes Berg authored
commit c0ce77b8 upstream. Reinette found the reason for the warnings that happened occasionally when a hw-offloaded scan finished; her description of the problem: mac80211 will defer the handling of scan requests if it is busy with management work at the time. The scan requests are deferred and run after the work has completed. When this occurs there are currently two problems. * The scan request for hardware scan is not fully populated with the band and channels to scan not initialized. * When the scan is queued the state is not correctly updated to reflect that a scan is in progress. The problem here is that when the driver completes the scan and calls ieee80211_scan_completed() a warning will be triggered since mac80211 was not aware that a scan was in progress. The reason is that the queued scan work will start the hw scan right away when the hw_scan_req struct has already been allocated. However, in the first pass it will not have been filled, which happens at the same time as setting the bits. To fix this, simply move the allocation after the pending work test as well, so that the first iteration of the scan work will call __ieee80211_start_scan() even in the hardware scan case. Bug-identified-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Daniel T Chen authored
commit e2595322 upstream. BugLink: https://bugs.launchpad.net/bugs/479373 The OR has verified with hda-verb that the internal microphone needs VREF50 set for audible capture. Signed-off-by:
Daniel T Chen <crimsun@ubuntu.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Neil Brown authored
commit 301e99ce upstream. One the changes in commit d7979ae4 "svc: Move close processing to a single place" is: err_delete: - svc_delete_socket(svsk); + set_bit(SK_CLOSE, &svsk->sk_flags); return -EAGAIN; This is insufficient. The recvfrom methods must always call svc_xprt_received on completion so that the socket gets re-queued if there is any more work to do. This particular path did not make that call because it actually destroyed the svsk, making requeue pointless. When the svc_delete_socket was change to just set a bit, we should have added a call to svc_xprt_received, This is the problem that b0401d72 attempted to fix, incorrectly. Signed-off-by:
J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by:
-
J. Bruce Fields authored
commit 1b644b6e upstream. This reverts commit b0401d72, which moved svc_delete_xprt() outside of XPT_BUSY, and allowed it to be called after svc_xpt_recived(), removing its last reference and destroying it after it had already been queued for future processing. Signed-off-by:
-
J. Bruce Fields authored
commit f5822754 upstream. This reverts commit b292cf9c. The commit that it attempted to patch up, b0401d72, was fundamentally wrong, and will also be reverted. Signed-off-by:
-
J. Bruce Fields authored
commit dc83d6e2 upstream. For nfsd we provide users the option of mapping uid's to server-side supplementary group lists. That makes sense for nfsd, but not necessarily for other rpc users (such as the callback client). So move that lookup to svcauth_unix_set_client, which is a program-specific method. Signed-off-by:
-
NeilBrown authored
commit 627a2d3c 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:
-
Mathieu Desnoyers authored
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 720eba31 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:
-
Mathieu Desnoyers authored
The mainline kernel as of 2.6.34-rc5 is not affected by this problem because commit 10fad5e4 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 8e18257d 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 authored
Mainline does not need this fix, as commit 259354de 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 6b588c18 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:
-
Ping Cheng authored
commit 014f6150 upstream. When Wacom devices wake up from a sleep, the switch mode command (wacom_query_tablet_data) is needed before wacom_open is called. wacom_query_tablet_data should not be executed inside wacom_open since wacom_open is called more than once during probe. Reported-and-tested-by:
Anton Anikin <Anton@Anikin.name> Signed-off-by:
Ping Cheng <pingc@wacom.com> Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
-
Alexey Starikovskiy authored
commit 2060c445 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=14667Signed-off-by:
Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
-
Alexey Starikovskiy authored
commit dadf28a1 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:
-
Peter Zijlstra authored
original patch commit ids: 452a339a and 134fbadf 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:
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:
-
