- 09 Feb, 2010 6 commits
-
-
Martin Schwidefsky authored
commit 21ec7f6d upstream. If irq flags tracing is enabled the TRACE_IRQS_ON macros expands to a function call which clobbers registers %r0-%r5. The macro is used in the code path for single stepped system calls. The argument registers %r2-%r6 need to be restored from the stack before the system call function is called. Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Stefan Richter authored
commit 7a481436 upstream. Unsurprisingly, Texas Instruments TSB43AB23 exhibits the same behaviour as TSB43AB22/A in dual buffer IR DMA mode: If descriptors are located at physical addresses above the 31 bit address range (2 GB), the controller will overwrite random memory. With luck, this merely prevents video reception. With only a little less luck, the machine crashes. We use the same workaround here as with TSB43AB22/A: Switch off the dual buffer capability flag and use packet-per-buffer IR DMA instead. Another possible workaround would be to limit the coherent DMA mask to 31 bits. In Linux 2.6.33, this change serves effectively only as documentation since dual buffer mode is not used for any controller anymore. But somebody might want to re-enable it in the future to make use of features of dual buffer DMA that are not available in packet-per-buffer mode. In Linux 2.6.32 and older, this update is vital for anyone with this controller, more than 2 GB RAM, a 64 bit kernel, and FireWire video or audio applications. We have at least four reports: http://bugzilla.kernel.org/show_bug.cgi?id=13808 http://marc.info/?l=linux1394-user&m=126154279004083 https://bugzilla.redhat.com/show_bug.cgi?id=552142 http://marc.info/?l=linux1394-user&m=126432246128386 Reported-by: Paul Johnson Reported-by: Ronneil Camara Reported-by: G Zornetzer Reported-by: Mark Thompson Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by:
-
Chris Wilson authored
commit 4bdadb97 upstream. Having missed the ENOMEM return via i915_gem_fault(), there are probably other paths that I also missed. By not enabling NORETRY by default these paths can run the shrinker and take memory from the system (but not from our own inactive lists because our shrinker can not run whilst we hold the struct mutex) and this may allow the system to survive a little longer whilst our drivers consume all available memory. References: OOM killer unexpectedly called with kernel 2.6.32 http://bugzilla.kernel.org/show_bug.cgi?id=14933 v2: Pass gfp into page mapping. v3: Use new read_cache_page_gfp() instead of open-coding. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Eric Anholt <eric@anholt.net> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Linus Torvalds authored
commit 0531b2aa upstream. It's a simplified 'read_cache_page()' which takes a page allocation flag, so that different paths can control how aggressive the memory allocations are that populate a address space. In particular, the intel GPU object mapping code wants to be able to do a certain amount of own internal memory management by automatically shrinking the address space when memory starts getting tight. This allows it to dynamically use different memory allocation policies on a per-allocation basis, rather than depend on the (static) address space gfp policy. The actual new function is a one-liner, but re-organizing the helper functions to the point where you can do this with a single line of code is what most of the patch is all about. Tested-by:
-
Anatolij Gustschin authored
commit f1053a7c upstream. Since commit 9d2e9d66 mptsas driver fails to allocate memory for the MPT chain buffers for second LSI adapter on PPC440SPe Katmai platform: ... ioc1: LSISAS1068E B3: Capabilities={Initiator} mptbase: ioc1: ERROR - Unable to allocate Reply, Request, Chain Buffers! mptbase: ioc1: ERROR - didn't initialize properly! (-3) mptsas: probe of 0002:31:00.0 failed with error -3 This commit increased MPT_FC_CAN_QUEUE value but initChainBuffers() doesn't differentiate between SAS and FC causing increased allocation for SAS case, too. Later pci_alloc_consistent() fails to allocate increased chain buffer pool size for SAS case. Provide a fix by looking at the bus type and using appropriate MPT_SAS_CAN_QUEUE value while calculation of the number of chain buffers. Signed-off-by:
Anatolij Gustschin <agust@denx.de> Acked-by:
Kashyap Desai <kashyap.desai@lsi.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Signed-off-by:
-
Boaz Harrosh authored
commit 63c43b0e upstream. Because of the terrible structuring of scsi-bidi-commands it breaks some of the life time rules of a scsi-command. It is now not allowed to free up the block-request before cleanup and partial deallocation of the scsi-command. (Which is not so for none bidi commands) The right fix to this problem would be to make bidi command a first citizen by allocating a scsi_sdb pointer at scsi command just like cmd->prot_sdb. The bidi sdb should be allocated/deallocated as part of the get/put_command (Again like the prot_sdb) and the current decoupling of scsi_cmnd and blk-request should be kept. For now make sure scsi_release_buffers() is called before the call to blk_end_request_all() which might cause the suicide of the block requests. At best the leak of bidi buffers, at worse a crash, as there is a race between the existence of the bidi_request and the free of the associated bidi_sdb. The reason this was never hit before is because only OSD has the potential of doing asynchronous bidi commands. (So does bsg but it is never used) And OSD clients just happen to do all their bidi commands synchronously, up until recently. Signed-off-by:
Boaz Harrosh <bharrosh@panasas.com> Signed-off-by:
-
- 28 Jan, 2010 34 commits
-
-
Greg Kroah-Hartman authored
-
Russ Anderson authored
commit da482474 upstream. Pass the number of minors when unregistering MSR and CPUID drivers. Reported-by:
Dean Nelson <dnelson@redhat.com> Signed-off-by:
Russ Anderson <rja@sgi.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Greg Kroah-Hartman authored
commit b04da8bf upstream. Commit 70362511 exposed that f_modown() should call write_lock_irqsave instead of just write_lock_irq so that because a caller could have a spinlock held and it would not be good to renable interrupts. Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Al Viro <viro@ZenIV.linux.org.uk> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Tavis Ormandy <taviso@google.com> Signed-off-by:
-
Wey-Yi Guy authored
commit 1152dcc2 upstream Similar to 6000 and 1000 series, RTS/CTS is the recommended protection mechanism for 5000 series in HT mode based on the HW design. Using RTS/CTS will better protect the inner exchange from interference, especially in highly-congested environment, it also prevent uCode encounter TX FIFO underrun and other HT mode related performance issues. Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Len Brown authored
upstream in 2.6.33-rc: 5d76b6f6 Refreshed here for 2.6.32.y, applies w/ offset back to 2.6.29.y. Linux has always ignored ACPI BIOS C2 with exit latency > 100 usec, and the ACPI spec is clear that is correct FADT-supplied C2. However, the ACPI spec explicitly states that _CST-supplied C-states have no latency limits. So move the 100usec C2 test out of the code shared by FADT and _CST code-paths, and into the FADT-specific path. This bug has not been visible until Nehalem, which advertises a CPU-C2 worst case exit latency on servers of 205usec. That (incorrect) figure is being used by BIOS writers on mobile Nehalem systems for the AC configuration. Thus, Linux ignores C2 leaving just C1, which is saves less power, and also impacts performance by preventing the use of turbo mode. http://bugzilla.kernel.org/show_bug.cgi?id=15064Tested-by:
Alex Chiang <achiang@hp.com> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
-
Pallipadi, Venkatesh authored
commit 6c56ccec upstream. Commit 83ce4009 did the following change If the TSC is constant and non-stop, also set it reliable. But, there seems to be few systems that will end up with TSC warp across sockets, depending on how the cpus come out of reset. Skipping TSC sync test on such systems may result in time inconsistency later. So, reenable TSC sync test even on constant and non-stop TSC systems. Set, sched_clock_stable to 1 by default and reset it in mark_tsc_unstable, if TSC sync fails. This change still gives perf benefit mentioned in 83ce4009 for systems where TSC is reliable. Signed-off-by:
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Acked-by:
Suresh Siddha <suresh.b.siddha@intel.com> LKML-Reference: <20091217202702.GA18015@linux-os.sc.intel.com> Signed-off-by:
-
David J. Wilder authored
commit 0cd4d0fd upstream. IPoIB can miss a change in destination GID under some conditions. The problem is caused when ipoib_neigh->dgid contains a stale address. The fix is to set ipoib_neigh->dgid to zero in ipoib_neigh_alloc(). This can happen when a system using bonding on its IPoIB interfaces has switched its active interface from interface A to B and back to A. The system that fails over will not correctly processes the 2nd address change, as described below. When an address has changed neighbor->ha is updated with the new address. Each neighbor has an associated ipoib_neigh. ipoib_neigh->dgid also holds a copy of the remote node's hardware address. When an address changes neighbor->ha is updated by the network layer (arp code) with the new address. IPoIB detects this change in ipoib_start_xmit() by comparing neighbor->ha with ipoib_neigh->dgid. The bug is that ipoib_neigh->dgid may already contain the new address (A) thus the change from B to A is missed by ipoib. Here is the sequence of events: ipoib_neigh->dgid = A and neighbor->ha = A The address is switched to B (the first switch) neighbor->ha = B The change is seen in ipoib_start_xmit() -- neighbor->ha != ipoib_neigh->dgid so ipoib_neigh is released, and a new one is allocated. The allocator may return the same chunk of memory that was just released, therefore ipoib_neigh->dgid still contains A at this point. ipoib_neigh->dgid should be updated in neigh_add_path(), but if the following conditions are true dgid is not updated: 1) __path_find() returns a path 2) path->ah is NULL The remote system now switches from address B to A, neighbor->ha is updated to A. Now we have again : ipoib_neigh->dgid = A and neighbor->ha = A Since the addresses are the same ipoib won't process the change in address. Fix this by zeroing out the dgid field when allocating a new struct ipoib_neigh. Signed-off-by:
David Wilder <dwilder@us.ibm.com> Signed-off-by:
Roland Dreier <rolandd@cisco.com> Signed-off-by:
-
Marcelo Tosatti authored
commit e50212bb upstream. Otherwise kvm might attempt to dereference a NULL pointer. Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
Avi Kivity <avi@redhat.com> Signed-off-by:
-
Jiri Slaby authored
commit 0c6ddceb upstream. Stanse found 2 lock imbalances in kvm_request_irq_source_id and kvm_free_irq_source_id. They omit to unlock kvm->irq_lock on fail paths. Fix that by adding unlock labels at the end of the functions and jump there from the fail paths. Signed-off-by:
Jiri Slaby <jirislaby@gmail.com> Cc: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
-
Wei Yongjun authored
commit 443c39bc upstream. In function kvm_arch_vcpu_init(), if the memory malloc for vcpu->arch.mce_banks is fail, it does not free the memory of lapic date. This patch fixed it. Signed-off-by:
Wei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by:
-
Wei Yongjun authored
commit 36cb93fd upstream. vcpu->arch.mce_banks is malloc in kvm_arch_vcpu_init(), but never free in any place, this may cause memory leak. So this patch fixed to free it in kvm_arch_vcpu_uninit(). Signed-off-by:
-
Sheng Yang authored
commit 82b7005f upstream. When found a error hva, should not return PAGE_SIZE but the level... Also clean up the coding style of the following loop. Signed-off-by:
Sheng Yang <sheng@linux.intel.com> Signed-off-by:
-
Marcelo Tosatti authored
commit a6085fba upstream. Exit the guest pagetable walk loop if reading gpte failed. Otherwise its possible to enter an endless loop processing the previous present pte. Signed-off-by:
-
Avi Kivity authored
commit a5d36f82 upstream. When we queue an interrupt to the local apic, we set the IRR before the TMR. The vcpu can pick up the IRR and inject the interrupt before setting the TMR, and perhaps even EOI it, causing incorrect behaviour. The race is really insignificant since it can only occur on the first interrupt (usually following interrupts will not change TMR), but it's better closed than open. Fixed by reordering setting the TMR vs IRR. Signed-off-by:
-
Michael S. Tsirkin authored
commit f1d1c309 upstream. Looks like repeatedly binding same fd to multiple gsi's with irqfd can use up a ton of kernel memory for irqfd structures. A simple fix is to allow each fd to only trigger one gsi: triggering a storm of interrupts in guest is likely useless anyway, and we can do it by binding a single gsi to many interrupts if we really want to. Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Acked-by:
Acked-by: Gregory Haskins <ghaskins@novell.com> Signed-off-by:
-
Christian Borntraeger authored
commit 062d5e9b upstream. kvm_handle_sie_intercept uses a jump table to get the intercept handler for a SIE intercept. Static code analysis revealed a potential problem: the intercept_funcs jump table was defined to contain (0x48 >> 2) entries, but we only checked for code > 0x48 which would cause an off-by-one array overflow if code == 0x48. Use the compiler and ARRAY_SIZE to automatically set the limits. Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
-
Abhijeet Kolekar authored
commit 5f612033 upstream. Patch fixes the bug at http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2139 Currently we cannot set the channel using wext extension if we have already associated and disconnected. As cfg80211_mgd_wext_siwfreq will not switch the channel if ssid is set. This fixes it by clearing the ssid. Following is the sequence which it tries to fix. modprobe iwlagn iwconfig wlan0 essid "" ifconfig wlan0 down iwconfig wlan0 chan X wext is marked as deprecate.If we use nl80211 we can easily play with setting the channel. Signed-off-by:
Abhijeet Kolekar <abhijeet.kolekar@intel.com> Acked-by:
Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
-
Benoit Papillault authored
commit e5de30c9 upstream. ieee80211_set_power_mgmt is meant for STA interfaces only. Moreover, since sdata->u.mgd.mtx is only initialized for STA interfaces, using this code for any other type of interface (like creating a monitor interface) will result in a oops. Signed-off-by:
Benoit Papillault <benoit.papillault@free.fr> Signed-off-by:
-
Guennadi Liakhovetski authored
commit 40aa7030 upstream. Remember to free the temporary register-cache. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Acked-by:
Liam Girdwood <lrg@slimlogic.co.uk> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Peter Horton authored
commit ff998793 upstream. The in kernel copy of a volume's update marker is not initialised from the volume table. This means that volumes where an update was unfinnished will not be treated as "forbidden to use". This is basically that the update functionality was broken. Signed-off-by:
Peter Horton <zero@colonel-panic.org> Signed-off-by:
Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by:
-
Artem Bityutskiy authored
commit ebddd63b upstream. When truncating an UBI volume, UBI should allocates a PEB-sized buffer but does not release it, which leads to memory leaks. This patch fixes the issue. Reported-by:
Marek Skuczynski <mareksk7@gmail.com> Signed-off-by:
-
Hans de Goede authored
commit c453615f upstream. When /dev/watchdog gets opened a second time we return -EBUSY, but we already have got a kref then, so we end up leaking our data struct. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Takashi Iwai authored
commit dc99be47 upstream. This patch fixes the aut-mute setup on HP T5735 with ALC262 codec. Instead of wrong amp, use pin control toggling for muting the speaker now. Tested-by:
Lee Trager <lee.trager@hp.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Serge E. Hallyn authored
commit 7d6feeb2 upstream. We have apparently had a memory leak since 7ca7e564 "ipc: store ipcs into IDRs" in 2007. The idr of which 3 exist for each ipc namespace is never freed. This patch simply frees them when the ipcns is freed. I don't believe any idr_remove() are done from rcu (and could therefore be delayed until after this idr_destroy()), so the patch should be safe. Some quick testing showed no harm, and the memory leak fixed. Caught by kmemleak. Signed-off-by:
Serge E. Hallyn <serue@us.ibm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Nick Piggin <npiggin@suse.de> Signed-off-by:
-
Ursula Braun authored
commit 998221c2 upstream. tx_bytes value must be updated by skb length before skb is freed. Signed-off-by:
Ursula Braun <ursula.braun@de.ibm.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Acked-by:
John Jolly <jjolly@suse.de> Signed-off-by:
-
Peter Oberparleiter authored
commit 16b9a057 upstream. Remove the call to BUG() for situations which are unexpected but do not cause actual problems. Signed-off-by:
Peter Oberparleiter <peter.oberparleiter@de.ibm.com> Signed-off-by:
-
Peter Oberparleiter authored
commit 48e4c385 upstream. io_subchannel_probe() frees memory for sch->private which is later freed again when io_subchannel_remove() is called. Fix this problem by removing the cleanup in io_subchannel_probe(). Signed-off-by:
-
Laurent Pinchart authored
commit 385097e0 upstream. The control blacklisting code erroneously used usb_match_id() by passing a pointer to a usb_device_id structure instead of an array of such structures. Replace the usb_match_id() call by usb_match_id_one(). Thanks to Paulo Assis for diagnosing the bug and providing an initial fix. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
NeilBrown authored
commit 0f9552b5 upstream. The start_ro modules parameter can be used to force arrays to be started in 'auto-readonly' in which they are read-only until the first write. This ensures that no resync/recovery happens until something else writes to the device. This is important for resume-from-disk off an md array. However if an array is started 'readonly' (by writing 'readonly' to the 'array_state' sysfs attribute) we want it to be really 'readonly', not 'auto-readonly'. So strengthen the condition to only set auto-readonly if the array is not already read-only. Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
commit 69385943 upstream. Fix erroneous check for ap->udma_mask in do_pata_set_dmamode() resulting in controller not being programmed properly for MWDMA. Signed-off-by:
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Shaohua Li authored
commit 1b677afd upstream. I obseved there is a sata_async_notification() for every ahci interrupt. But the async notification does nothing (this is hard disk drive and no pmp). This cause cpu wastes some time on sntf register access. It appears ICH AHCI doesn't support SNotification register, but the controller reports it does. After quirking it, the async notification disappears. PS. it appears all ICH don't support SNotification register from ICH manual, don't know if we need quirk all ICH. I don't have machines with all kinds of ICH. Signed-off-by:
Shaohua Li <shaohua.li@intel.com> Signed-off-by:
-
Seth Heasley authored
commit 3c9d8ecc upstream. This patch adds the Intel Cougar Point and PCH DeviceIDs for iTCO Watchdog. Signed-off-by:
Seth Heasley <seth.heasley@intel.com> Signed-off-by:
Wim Van Sebroeck <wim@iguana.be> Acked-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Imre Kaloz authored
commit 4946f835 upstream. add PCI ID for the Intel EP80579 (Tolapai) SoC Signed-off-by:
Imre Kaloz <kaloz@openwrt.org> Signed-off-by:
-
Wim Van Sebroeck authored
commit cb711a19 upstream. Cleanup the documentation about the supported chipsets. [needed for further device ids to add to this driver - gkh] Signed-off-by:
-
