- 26 Apr, 2010 40 commits
-
-
Mike Travis authored
commit 773a38db upstream. Update the VGA Arbiter to accept PCI Domains other than 0. Signed-off-by:
Mike Travis <travis@sgi.com> LKML-Reference: <201002022238.o12McFe8018730@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>
-
Youquan Song authored
commit b49bfd32 upstream. The Correcteable/Uncorrectable Error Mask Registers are used by PCIe AER driver which will controls the reporting of individual errors to PCIe RC via PCIe error messages. If hardware masks special error reporting to RC, the aer_inject driver should not inject aer error. Acked-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
Youquan Song <youquan.song@intel.com> Acked-by:
Ying Huang <ying.huang@intel.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Alexander Duyck authored
commit 747d49ba upstream. This patch adds the device ID necessary to support the 82576NS SerDes adapter. Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Mike Christie authored
commit 3f9daedf upstream. The scsi ioctl code path was missing scsi target reset support. This patch just adds it. Signed-off-by:
Mike Christie <michaelc@cs.wisc.edu> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Mike Christie authored
commit 2bc1c59d upstream. If the port state is blocked and the fast io fail tmo has fired then this patch will fail bsg requests immediately. This is needed if userspace is sending IOs to test the transport like with fcping, so it will not have to wait for the dev loss tmo. With this patch he bsg req fast io fail code behaves like the normal and sg io/passthrough fast io fail. Signed-off-by:
James Smart <james.smart@emulex.com> Signed-off-by:
-
Sachin Prabhu authored
commit f78233dd 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:
-
Tao Ma authored
commit 78c37eb0 upstream. In ocfs2_validate_gd_parent, we check bg_chain against the cl_next_free_rec of the dinode. Actually in resize, we have the chance of bg_chain == cl_next_free_rec. So add some additional condition check for it. I also rename paramter "clean_error" to "resize", since the old one is not clearly enough to indicate that we should only meet with this case in resize. btw, the correpsonding bug is http://oss.oracle.com/bugzilla/show_bug.cgi?id=1230. Signed-off-by:
Tao Ma <tao.ma@oracle.com> Signed-off-by:
Joel Becker <joel.becker@oracle.com> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Mark Fasheh authored
commit fcefd25a upstream. ocfs2_set_acl() and ocfs2_init_acl() were setting i_mode on the in-memory inode, but never setting it on the disk copy. Thus, acls were some times not getting propagated between nodes. This patch fixes the issue by adding a helper function ocfs2_acl_set_mode() which does this the right way. ocfs2_set_acl() and ocfs2_init_acl() are then updated to call ocfs2_acl_set_mode(). Signed-off-by:
Mark Fasheh <mfasheh@suse.com> Signed-off-by:
-
Bernd Porr authored
commit d4c3a565 upstream. Jan-Matthias Braun spotted a bug which locks up the driver when the comedi ring buffer runs empty and provided a patch. The driver would still send the data to comedi but the reader won't wake up any more. What's required is setting the flag COMEDI_CB_BLOCK after new data has arrived which wakes up the reader and therefore the read() command. Signed-off-by:
Bernd Porr <berndporr@f2s.com> Signed-off-by:
Leann Ogasawara <leann.ogasawara@canonical.com> Signed-off-by:
-
Bernd Porr authored
commit ea25371a upstream. I've fixed a bug in the USBDUX driver which caused timeouts while sending commands to the boards. This was mainly because of one bulk transfer which had a timeout of 1ms (!). I've now set all timeouts to 1000ms. From: Bernd Porr <BerndPorr@f2s.com> Signed-off-by:
-
Andrew Perepechko authored
commit 08261673 upstream. dq_flags are modified non-atomically in do_set_dqblk via __set_bit calls and atomically for example in mark_dquot_dirty or clear_dquot_dirty. Hence a change done by an atomic operation can be overwritten by a change done by a non-atomic one. Fix the problem by using atomic bitops even in do_set_dqblk. Signed-off-by:
Andrew Perepechko <andrew.perepechko@sun.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Kiyoshi Ueda authored
upstream commit 9eef87da backported to 2.6.32.10 by Nikanth Karthikesan <knikanth@suse.de> This patch fixes the problem that system may stall if target's ->map_rq returns DM_MAPIO_REQUEUE in map_request(). E.g. stall happens on 1 CPU box when a dm-mpath device with queue_if_no_path bounces between all-paths-down and paths-up on I/O load. When target's ->map_rq returns DM_MAPIO_REQUEUE, map_request() requeues the request and returns to dm_request_fn(). Then, dm_request_fn() doesn't exit the I/O dispatching loop and continues processing the requeued request again. This map and requeue loop can be done with interrupt disabled, so 1 CPU system can be stalled if this situation happens. For example, commands below can stall my 1 CPU box within 1 minute or so: # dmsetup table mp mp: 0 2097152 multipath 1 queue_if_no_path 0 1 1 service-time 0 1 2 8:144 1 1 # while true; do dd if=/dev/mapper/mp of=/dev/null bs=1M count=100; done & # while true; do \ > dmsetup message mp 0 "fail_path 8:144" \ > dmsetup suspend --noflush mp \ > dmsetup resume mp \ > dmsetup message mp 0 "reinstate_path 8:144" \ > done To fix the problem above, this patch changes dm_request_fn() to exit the I/O dispatching loop once if a request is requeued in map_request(). Signed-off-by:
Kiyoshi Ueda <k-ueda@ct.jp.nec.com> Signed-off-by:
Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Signed-off-by:
Alasdair G Kergon <agk@redhat.com> Signed-off-by:
Nikanth Karthikesan <knikanth@suse.de> Signed-off-by:
-
Al Viro authored
commit 462d6057 upstream. RFC says we need to follow the chain of mounts if there's more than one stacked on that point. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Avi Kivity authored
commit 0d1622d7 upstream. The Intel Architecture Optimization Reference Manual states that a short load that follows a long store to the same object will suffer a store forwading penalty, particularly if the two accesses use different addresses. Trivially, a long load that follows a short store will also suffer a penalty. __downgrade_write() in rwsem incurs both penalties: the increment operation will not be able to reuse a recently-loaded rwsem value, and its result will not be reused by any recently-following rwsem operation. A comment in the code states that this is because 64-bit immediates are special and expensive; but while they are slightly special (only a single instruction allows them), they aren't expensive: a test shows that two loops, one loading a 32-bit immediate and one loading a 64-bit immediate, both take 1.5 cycles per iteration. Fix this by changing __downgrade_write to use the same add instruction on i386 and on x86_64, so that it uses the same operand size as all the other rwsem functions. Signed-off-by:
Avi Kivity <avi@redhat.com> LKML-Reference: <1266049992-17419-1-git-send-email-avi@redhat.com> Signed-off-by:
-
Linus Torvalds authored
commit 4126faf0 upstream. The patches 5d0b7235 and bafaecd1 broke the UML build: On Sun, 17 Jan 2010, Ingo Molnar wrote: > > FYI, -tip testing found that these changes break the UML build: > > kernel/built-in.o: In function `__up_read': > /home/mingo/tip/arch/x86/include/asm/rwsem.h:192: undefined reference to `call_rwsem_wake' > kernel/built-in.o: In function `__up_write': > /home/mingo/tip/arch/x86/include/asm/rwsem.h:210: undefined reference to `call_rwsem_wake' > kernel/built-in.o: In function `__downgrade_write': > /home/mingo/tip/arch/x86/include/asm/rwsem.h:228: undefined reference to `call_rwsem_downgrade_wake' > kernel/built-in.o: In function `__down_read': > /home/mingo/tip/arch/x86/include/asm/rwsem.h:112: undefined reference to `call_rwsem_down_read_failed' > kernel/built-in.o: In function `__down_write_nested': > /home/mingo/tip/arch/x86/include/asm/rwsem.h:154: undefined reference to `call_rwsem_down_write_failed' > collect2: ld returned 1 exit status Add lib/rwsem_64.o to the UML subarch objects to fix. LKML-Reference: <alpine.LFD.2.00.1001171023440.13231@localhost.localdomain> Signed-off-by:
-
Linus Torvalds authored
commit bafaecd1 upstream. This one is much faster than the spinlock based fallback rwsem code, with certain artifical benchmarks having shown 300%+ improvement on threaded page faults etc. Again, note the 32767-thread limit here. So this really does need that whole "make rwsem_count_t be 64-bit and fix the BIAS values to match" extension on top of it, but that is conceptually a totally independent issue. NOT TESTED! The original patch that this all was based on were tested by KAMEZAWA Hiroyuki, but maybe I screwed up something when I created the cleaned-up series, so caveat emptor.. Also note that it _may_ be a good idea to mark some more registers clobbered on x86-64 in the inline asms instead of saving/restoring them. They are inline functions, but they are only used in places where there are not a lot of live registers _anyway_, so doing for example the clobbers of %r8-%r11 in the asm wouldn't make the fast-path code any worse, and would make the slow-path code smaller. (Not that the slow-path really matters to that degree. Saving a few unnecessary registers is the _least_ of our problems when we hit the slow path. The instruction/cycle counting really only matters in the fast path). Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> LKML-Reference: <alpine.LFD.2.00.1001121810410.17145@localhost.localdomain> Signed-off-by:
-
H. Peter Anvin authored
commit 1838ef1d upstream. For x86-64, 32767 threads really is not enough. Change rwsem_count_t to a signed long, so that it is 64 bits on x86-64. This required the following changes to the assembly code: a) %z0 doesn't work on all versions of gcc! At least gcc 4.4.2 as shipped with Fedora 12 emits "ll" not "q" for 64 bits, even for integer operands. Newer gccs apparently do this correctly, but avoid this problem by using the _ASM_ macros instead of %z. b) 64 bits immediates are only allowed in "movq $imm,%reg" constructs... no others. Change some of the constraints to "e", and fix the one case where we would have had to use an invalid immediate -- in that case, we only care about the upper half anyway, so just access the upper half. Signed-off-by:
-
Linus Torvalds authored
commit 5d0b7235 upstream. The fast version of the rwsems (the code that uses xadd) has traditionally only worked on x86-32, and as a result it mixes different kinds of types wildly - they just all happen to be 32-bit. We have "long", we have "__s32", and we have "int". To make it work on x86-64, the types suddenly matter a lot more. It can be either a 32-bit or 64-bit signed type, and both work (with the caveat that a 32-bit counter will only have 15 bits of effective write counters, so it's limited to 32767 users). But whatever type you choose, it needs to be used consistently. This makes a new 'rwsem_counter_t', that is a 32-bit signed type. For a 64-bit type, you'd need to also update the BIAS values. Signed-off-by:
-
Linus Torvalds authored
commit 59c33fa7 upstream. This makes gcc use the right register names and instruction operand sizes automatically for the rwsem inline asm statements. So instead of using "(%%eax)" to specify the memory address that is the semaphore, we use "(%1)" or similar. And instead of forcing the operation to always be 32-bit, we use "%z0", taking the size from the actual semaphore data structure itself. This doesn't actually matter on x86-32, but if we want to use the same inline asm for x86-64, we'll need to have the compiler generate the proper 64-bit names for the registers (%rax instead of %eax), and if we want to use a 64-bit counter too (in order to avoid the 15-bit limit on the write counter that limits concurrent users to 32767 threads), we'll need to be able to generate instructions with "q" accesses rather than "l". Since this header currently isn't enabled on x86-64, none of that matters, but we do want to use the xadd version of the semaphores rather than have to take spinlocks to do a rwsem. The mm->mmap_sem can be heavily contended when you have lots of threads all taking page faults, and the fallback rwsem code that uses a spinlock performs abysmally badly in that case. [ hpa: modified the patch to skip size suffixes entirely when they are redundant due to register operands. ] Signed-off-by:
-
Eugene Teo authored
Commit 77c1ff39 fixed the userspace pointer dereference, but introduced another bug pointed out by Eugene Teo in RH bug #564264. Instead of comparing the point we were at in the string, we instead compared the beginning of the string to "default". Signed-off-by:
Eugene Teo <eugeneteo@kernel.sg> Signed-off-by:
-
Borislav Petkov authored
commit cb19060a upstream. Final stage linking can fail with arch/x86/built-in.o: In function `store_cache_disable': intel_cacheinfo.c:(.text+0xc509): undefined reference to `amd_get_nb_id' arch/x86/built-in.o: In function `show_cache_disable': intel_cacheinfo.c:(.text+0xc7d3): undefined reference to `amd_get_nb_id' when CONFIG_CPU_SUP_AMD is not enabled because the amd_get_nb_id helper is defined in AMD-specific code but also used in generic code (intel_cacheinfo.c). Reorganize the L3 cache index disable code under CONFIG_CPU_SUP_AMD since it is AMD-only anyway. Signed-off-by:
Borislav Petkov <borislav.petkov@amd.com> LKML-Reference: <20100218184210.GF20473@aftab> Signed-off-by:
-
Borislav Petkov authored
commit f619b3d8 upstream. The show/store_cache_disable routines depend unnecessarily on NUMA's cpu_to_node and the disabling of cache indices broke when !CONFIG_NUMA. Remove that dependency by using a helper which is always correct. While at it, enable L3 Cache Index disable on rev D1 Istanbuls which sport the feature too. Signed-off-by:
-
Borislav Petkov authored
commit 048a8774 upstream. We need to know the valid L3 indices interval when disabling them over /sysfs. Do that when the core is brought online and add boundary checks to the sysfs .store attribute. Signed-off-by:
-
Borislav Petkov authored
commit 897de50e upstream. The cache_disable_[01] attribute in /sys/devices/system/cpu/cpu?/cache/index[0-3]/ is enabled on all cache levels although only L3 supports it. Add it only to the cache level that actually supports it. Signed-off-by:
-
Borislav Petkov authored
commit 48a719c2 upstream. Simplify if-statement while at it. [ hpa: we need to #include <asm/smp.h> ] Cc: Dave Jones <davej@redhat.com> Cc: David Airlie <airlied@linux.ie> Signed-off-by:
-
Borislav Petkov authored
commit dcf39daf upstream. * Correct the masks used for writing the cache index disable indices. * Do not turn off L3 scrubber - it is not necessary. * Make sure wbinvd is executed on the same node where the L3 is. * Check for out-of-bounds values written to the registers. * Make show_cache_disable hex values unambiguous * Check for Erratum #388 Signed-off-by:
-
Borislav Petkov authored
commit a7b480e7 upstream. Add wbinvd_on_cpu and wbinvd_on_all_cpus stubs for executing wbinvd on a particular CPU. [ hpa: renamed lib/smp.c to lib/cache-smp.c ] [ hpa: wbinvd_on_all_cpus() returns int, but wbinvd() returns void. Thus, the former cannot be a macro for the latter, replace with an inline function. ] Signed-off-by:
-
Chris Wright authored
commit 8f9f55e8 upstream. This effectively reverts commit 61d047be. Disabling the IOMMU can potetially allow DMA transactions to complete without being translated. Leave it enabled, and allow crash kernel to do the IOMMU reinitialization properly. Cc: Joerg Roedel <joerg.roedel@amd.com> Cc: Eric Biederman <ebiederm@xmission.com> Cc: Neil Horman <nhorman@tuxdriver.com> Cc: Vivek Goyal <vgoyal@redhat.com> Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
Joerg Roedel <joerg.roedel@amd.com> Signed-off-by:
-
Chris Wright authored
commit 75f66533 upstream. Hit another kdump problem as reported by Neil Horman. When initializaing the IOMMU, we attach devices to their domains before the IOMMU is fully (re)initialized. Attaching a device will issue some important invalidations. In the context of the newly kexec'd kdump kernel, the IOMMU may have stale cached data from the original kernel. Because we do the attach too early, the invalidation commands are placed in the new command buffer before the IOMMU is updated w/ that buffer. This leaves the stale entries in the kdump context and can renders device unusable. Simply enable the IOMMU before we do the attach. Cc: Neil Horman <nhorman@tuxdriver.com> Cc: Vivek Goyal <vgoyal@redhat.com> Signed-off-by:
-
Joerg Roedel authored
commit 8b408fe4 upstream. In the amd_iommu_domain_destroy the protection_domain_free function is partly reimplemented. The 'partly' is the bug here because the domain is not deleted from the domain list. This results in use-after-free errors and data-corruption. Fix it by just using protection_domain_free instead. Signed-off-by:
-
Dave Airlie authored
commit 79b9517a upstream. This is an M24/X600 chip. From RH# 581927 Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Jerome Glisse authored
commit 30f69f3f upstream. Typo in in flush leaded to no flush of the RS600 tlb which ultimately leaded to massive system ram corruption, with this patch everythings seems to work properly. Signed-off-by:
Jerome Glisse <jglisse@redhat.com> Signed-off-by:
-
Alex Deucher authored
commit 08d07511 upstream. On systems with the tv dac shared between DVI and TV, we can only use the dac for one of the connectors. However, when using a digital monitor on the DVI port, you can use the dac for the TV connector just fine. Check the use_digital status when resolving the conflict. Fixes fdo bug 27649, possibly others. Signed-off-by:
Alex Deucher <alexdeucher@gmail.com> Signed-off-by:
-
Alex Deucher authored
commit d3a67a43 upstream. Switching between TV and VGA caused VGA to break on some systems since the TV encoder was left enabled when VGA was used. fixes fdo bug 25520. Signed-off-by:
-
Stefan Bader authored
commit 9875557e upstream. BugLink: http://bugs.launchpad.net/ubuntu/bugs/544671 This system claims to have a LVDS but has not. Signed-off-by:
Stephane Graber <stgraber@ubuntu.com> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Jean Delvare authored
commit c7a78d2c upstream. When CONFIG_REGULATOR isn't set, regulator_get_voltage() returns 0. Properly handle this case by not trusting the value. Reported-by:
Jerome Oufella <jerome.oufella@savoirfairelinux.com> Signed-off-by:
Jean Delvare <khali@linux-fr.org> Cc: Jonathan Cameron <jic23@cam.ac.uk> Acked-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Jerome Oufella authored
commit 328a2c22 upstream. I discovered two issues. First the previous sht15_calc_temp() loop did not iterate through the temppoints array since the (data->supply_uV > temppoints[i - 1].vdd) test is always true in this direction. Also the two-points linear interpolation function was returning biased values due to a stray division by 1000 which shouldn't be there. [JD: Also change the default value for d1 from 0 to something saner.] Signed-off-by:
Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by:
-
Takashi Iwai authored
commit 29aac005 upstream. usb-midi causes sometimes Oops at snd_usbmidi_output_drain() after disconnection. This is due to the access to the endpoints which have been already released at disconnection while the files are still alive. This patch fixes the problem by checking disconnection state at snd_usbmidi_output_drain() and by releasing urbs but keeping the endpoint instances until really all freed. Tested-by:
Tvrtko Ursulin <tvrtko@ursulin.net> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Joerg Schirottke authored
commit d1501ea8 upstream. Added the matching model for Clevo laptop M570U. Signed-off-by:
Joerg Schirottke <master@kanotix.com> Tested-by:
Maximilian Gerhard <maxbox@directbox.com> Signed-off-by:
-
Trond Myklebust authored
commit 0df5dd4a upstream. Arnaud Giersch reports that NFSv4 locking is broken when we hold a delegation since commit 8e469ebd (NFSv4: Don't allow posix locking against servers that don't support it). According to Arnaud, the lock succeeds the first time he opens the file (since we cannot do a delegated open) but then fails after we start using delegated opens. The following patch fixes it by ensuring that locking behaviour is governed by a per-filesystem capability flag that is initially set, but gets cleared if the server ever returns an OPEN without the NFS4_OPEN_RESULT_LOCKTYPE_POSIX flag being set. Reported-by:
Arnaud Giersch <arnaud.giersch@iut-bm.univ-fcomte.fr> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
