- 28 Jan, 2010 2 commits
-
-
H Hartley Sweeten authored
commit 8e1a928a upstream. Include "tick-internal.h" in order to pick up the extern function prototype for clockevents_shutdown(). This quiets the following sparse build noise: warning: symbol 'clockevents_shutdown' was not declared. Should it be static? Signed-off-by:
H Hartley Sweeten <hsweeten@visionengravers.com> LKML-Reference: <BD79186B4FD85F4B8E60E381CAEE190901E24550@mi8nycmail19.Mi8.com> Reviewed-by:
Yong Zhang <yong.zhang0@gmail.com> Cc: johnstul@us.ibm.com Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Xiaotian Feng authored
commit ea9d8e3f upstream. Marc reported that the BUG_ON in clockevents_notify() triggers on his system. This happens because the kernel tries to remove an active clock event device (used for broadcasting) from the device list. The handling of devices which can be used as per cpu device and as a global broadcast device is suboptimal. The simplest solution for now (and for stable) is to check whether the device is used as global broadcast device, but this needs to be revisited. [ tglx: restored the cpuweight check and massaged the changelog ] Reported-by:
Marc Dionne <marc.c.dionne@gmail.com> Tested-by:
Xiaotian Feng <dfeng@redhat.com> LKML-Reference: <1262834564-13033-1-git-send-email-dfeng@redhat.com> Signed-off-by:
-
- 25 Jan, 2010 30 commits
-
-
Greg Kroah-Hartman authored
-
Peter Zijlstra authored
commit 22e19085 upstream. Anton reported that perf record kept receiving events even after calling ioctl(PERF_EVENT_IOC_DISABLE). It turns out that FORK,COMM and MMAP events didn't respect the disabled state and kept flowing in. Reported-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Tested-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Peter Zijlstra authored
commit 5d27c23d upstream. Acme noticed that his FORK/MMAP numbers were inflated by about the same factor as his cpu-count. This led to the discovery of a few more sites that need to respect the event->cpu filter. Reported-by:
Arnaldo Carvalho de Melo <acme@ghostprotocols.net> Signed-off-by:
-
Arjan van de Ven authored
commit 8f06d7e6 upstream. A process that changes its comm field, does this on a per kernel task struct basis. The timechart tool used, incorrectly, the pid to track this, and should have used the tid instead... Signed-off-by:
Arjan van de Ven <arjan@linux.intel.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Mike Galbraith <efault@gmx.de> Cc: Paul Mackerras <paulus@samba.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> LKML-Reference: <20100116125319.34ac3edd@infradead.org> Signed-off-by:
-
Yongseok Koh authored
commit 88f50044 upstream. In free_unmap_area_noflush(), va->flags is marked as VM_LAZY_FREE first, and then vmap_lazy_nr is increased atomically. But, in __purge_vmap_area_lazy(), while traversing of vmap_are_list, nr is counted by checking VM_LAZY_FREE is set to va->flags. After counting the variable nr, kernel reads vmap_lazy_nr atomically and checks a BUG_ON condition whether nr is greater than vmap_lazy_nr to prevent vmap_lazy_nr from being negative. The problem is that, if interrupted right after marking VM_LAZY_FREE, increment of vmap_lazy_nr can be delayed. Consequently, BUG_ON condition can be met because nr is counted more than vmap_lazy_nr. It is highly probable when vmalloc/vfree are called frequently. This scenario have been verified by adding delay between marking VM_LAZY_FREE and increasing vmap_lazy_nr in free_unmap_area_noflush(). Even the vmap_lazy_nr is for checking high watermark, it never be the strict watermark. Although the BUG_ON condition is to prevent vmap_lazy_nr from being negative, vmap_lazy_nr is signed variable. So, it could go down to negative value temporarily. Consequently, removing the BUG_ON condition is proper. A possible BUG_ON message is like the below. kernel BUG at mm/vmalloc.c:517! invalid opcode: 0000 [#1] SMP EIP: 0060:[<c04824a4>] EFLAGS: 00010297 CPU: 3 EIP is at __purge_vmap_area_lazy+0x144/0x150 EAX: ee8a8818 EBX: c08e77d4 ECX: e7c7ae40 EDX: c08e77ec ESI: 000081fe EDI: e7c7ae60 EBP: e7c7ae64 ESP: e7c7ae3c DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Call Trace: [<c0482ad9>] free_unmap_vmap_area_noflush+0x69/0x70 [<c0482b02>] remove_vm_area+0x22/0x70 [<c0482c15>] __vunmap+0x45/0xe0 [<c04831ec>] vmalloc+0x2c/0x30 Code: 8d 59 e0 eb 04 66 90 89 cb 89 d0 e8 87 fe ff ff 8b 43 20 89 da 8d 48 e0 8d 43 20 3b 04 24 75 e7 fe 05 a8 a5 a3 c0 e9 78 ff ff ff <0f> 0b eb fe 90 8d b4 26 00 00 00 00 56 89 c6 b8 ac a5 a3 c0 31 EIP: [<c04824a4>] __purge_vmap_area_lazy+0x144/0x150 SS:ESP 0068:e7c7ae3c [ See also http://marc.info/?l=linux-kernel&m=126335856228090&w=2 ] Signed-off-by:
Yongseok Koh <yongseok.koh@samsung.com> Reviewed-by:
Minchan Kim <minchan.kim@gmail.com> Cc: Nick Piggin <npiggin@suse.de> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Ryan May authored
commit 10d2cdb6 upstream. Resolves kernel.org bug 14914. Remove entry for 2770:915d (usb digital camera with mass storage support) from unusual_devs.h. The fix triggered by the entry causes the file system on the camera to be completely inaccessible (no partition table, the device is not mountable). The patch works, but let me clarify a few things about it. All the patch does is remove the entry for this device from the drivers/usb/storage/unusual_devs.h, which is supposed to help with a problem with the device's reported size (I think). I'm pretty sure it was originally added for a reason, so I'm not sure removing it won't cause other problems to reappear. Also, I should note that this unusual_devs.h entry was present (and activating workarounds) in 2.6.29, but in that version everything works fine. Starting with 2.6.30, things no longer work. Signed-off-by:
Ryan May <rmay31@gmail.com> Cc: Rohan Hart <rohan.hart17@gmail.com> Signed-off-by:
-
Suresh Siddha authored
commit 2992e545 upstream. Thomas Schlichter reported: > X.org uses libpciaccess which tries to mmap with write combining enabled via > /sys/bus/pci/devices/*/resource0_wc. Currently, when PAT is not enabled, the > kernel does fall back to uncached mmap. Then libpciaccess thinks it succeeded > mapping with write combining enabled and does not set up suited MTRR entries. > ;-( Instead of silently mapping pci mmap region as UC minus in the case of !pat_enabled and wc request, we can return error. Eric Anholt mentioned that caller (like X) typically follows up with UC minus pci mmap request and if there is a free mtrr slot, caller will manage adding WC mtrr. Jesse Barnes says: > Older versions of libpciaccess will behave better if we do it that way > (iirc it only allocates an MTRR if the resource_wc file doesn't exist or > fails to get mapped). Reported-by:
Thomas Schlichter <thomas.schlichter@web.de> Signed-off-by:
Suresh Siddha <suresh.b.siddha@intel.com> Acked-by:
Eric Anholt <eric@anholt.net> Acked-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Martin K. Petersen authored
commit b27d7f16 upstream. Make DM use bdev_stack_limits() function so that partition offsets get taken into account when calculating alignment. Clarify stacking warnings. Also remove obsolete clearing of final alignment_offset and misalignment flag. Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Cc: Alasdair G. Kergon <agk@redhat.com> Signed-off-by:
Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
Martin K. Petersen authored
commit 17be8c24 upstream. DM does not want to know about partition offsets. Add a partition-aware wrapper that DM can use when stacking block devices. Signed-off-by:
Alasdair G Kergon <agk@redhat.com> Signed-off-by:
-
Zhao Yakui authored
commit 7c3f0a27 upstream. There exist multiple DDC buses for the SDVO cards with multiple outputs. When we can't get the EDID by using the select DDC bus, we can try the other possible DDC bus to see whether the EDID can be obtained. https://bugs.freedesktop.org/show_bug.cgi?id=23842Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Tested-by:
Sebastien Caty <sebastien.caty@mrnf.gouv.qc.ca> Signed-off-by:
-
Zhao Yakui authored
commit 6a304caf upstream. For some SDVO cards based on conexant chip, we can't read the EDID if we don't read the response after issuing SDVO DDC bus switch command. From the SDVO spec once when another I2C transaction is finished after completing the I2C transaction of issuing the bus switch command, it will be switched back to the SDVO internal state again. So we can't initiate a new I2C transaction to read the response after issuing the DDC bus switch command. Instead we should issue DDC bus switch command and read the response in the same I2C transaction. https://bugs.freedesktop.org/show_bug.cgi?id=23842 https://bugs.freedesktop.org/show_bug.cgi?id=24458 https://bugs.freedesktop.org/show_bug.cgi?id=24522 https://bugs.freedesktop.org/show_bug.cgi?id=24282Signed-off-by:
-
James Bottomley authored
commit cc9b2e9f upstream. Based on patch originally by Jeff Mahoney <jeffm@suse.com> enclosure_status is expected to be a NULL terminated array of strings but isn't actually NULL terminated. When writing an invalid value to /sys/class/enclosure/.../.../status, it goes off the end of the array and Oopses. Fix by making the assumption true and adding NULL at the end. Reported-by:
Artur Wojcik <artur.wojcik@intel.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Signed-off-by:
-
Alexey Starikovskiy authored
commit 54070101 upstream. Merge of poll and irq modes accelerated EC transaction, so that keyboard starts to suffer again. Add msleep(1) into transaction path for the storm to allow keyboard controller to do its job. Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14747Signed-off-by:
Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by:
Len Brown <len.brown@intel.com> Cc: François Valenduc <francois.valenduc@tvcablenet.be> Signed-off-by:
-
Alexey Starikovskiy authored
commit a62e8f19 upstream. Split EC query handling into acknowledge and execution phase. This allows much smaller pending query lattency and lowers chances of EC going "wild" and losing events. Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14858Signed-off-by:
-
Greg Kroah-Hartman authored
commit b132b04e upstream. These controllers say "unknown" for their speed in sysfs, which obviously isn't correct. Reported-by:
Kurt Garloff <garloff@novell.com> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: David Vrabel <david.vrabel@csr.com> Signed-off-by:
-
Alan Stern authored
commit 49d0f078 upstream. This patch (as1330) fixes a bug in khbud's handling of remote wakeups. When a device sends a remote-wakeup request, the parent hub (or the host controller driver, for directly attached devices) begins the resume sequence and notifies khubd when the sequence finishes. At this point the port's SUSPEND feature is automatically turned off. However the device needs an additional 10-ms resume-recovery time (TRSMRCY in the USB spec). Khubd does not wait for this delay if the SUSPEND feature is off, and as a result some devices fail to behave properly following a remote wakeup. This patch adds the missing delay to the remote-wakeup path. It also extends the resume-signalling delay used by ehci-hcd and uhci-hcd from 20 ms (the value in the spec) to 25 ms (the value we use for non-remote-wakeup resumes). The extra time appears to help some devices. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Cc: Rickard Bellini <rickard.bellini@ericsson.com> Signed-off-by:
-
Alan Stern authored
commit cec3a53c upstream. This patch (as1321) fixes a problem with EHCI and UHCI root-hub suspends: If the suspend occurs while a port is trying to resume, the resume doesn't finish and simply gets lost. When remote wakeup is enabled, this is undesirable behavior. The patch checks first to see if any port resumes are in progress, and if they are then it fails the root-hub suspend with -EBUSY. Signed-off-by:
-
Alan Stern authored
commit 1b9a38bf upstream. This patch (as1320) fixes two problems related to interrupt-URB scheduling in ehci-hcd. URBs with an interval of 2 or 4 microframes aren't handled. For the time being, the patch reduces to interval to 1 uframe. URBs are constrained to have an interval no larger than 1024 frames by usb_submit_urb(). But some EHCI controllers allow use of a schedule as short as 256 frames; for these controllers we may have to decrease the interval to the actual schedule length. The second problem isn't very significant since few devices expose interrupt endpoints with an interval larger than 256 frames. But the first problem is critical; it will prevent the kernel from working with devices having interrupt intervals of 2 or 4 uframes. Signed-off-by:
Glynn Farrow <farrowg@sg.ibm.com> Signed-off-by:
-
Oliver Neukum authored
commit acbe2feb upstream. Memory allocations with GFP_KERNEL can cause IO to a storage device which can fail resulting in a need to reset the device. Therefore GFP_KERNEL cannot be safely used between usb_lock_device() and usb_unlock_device(). Replace by GFP_NOIO. Signed-off-by:
Oliver Neukum <oliver@neukum.org> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Alan Stern authored
commit a91b593e upstream. This patch adds a mask bit which was mistakenly omitted from the as1311 patch (usb-storage: add BAD_SENSE flag). Signed-off-by:
-
Johan Hovold authored
commit 25915302 upstream. Fix a regression introduced by commit 715b1dc0 ("USB: usb_debug, usb_generic_serial: implement multi urb write"). URB transfer buffer was never freed when using multi-urb writes. Currently the only driver enabling multi-urb writes is usb_debug. Signed-off-by:
Johan Hovold <jhovold@gmail.com> Cc: Greg KH <greg@kroah.com> Acked-by:
Jason Wessel <jason.wessel@windriver.com> Signed-off-by:
-
Matthew Garrett authored
commit 6d34855d upstream. Wacom claims that the WACF namespace will always be devoted to serial Wacom tablets. Remove the existing entries and add a wildcard to avoid having to update the kernel every time they add a new device. Signed-off-by:
Ping Cheng <pingc@wacom.com> Signed-off-by:
Matthew Garrett <mjg@redhat.com> Tested-by:
-
Alan Cox authored
commit eeec32a7 upstream. Nozomi goes wrong if you get the sequence open open close [stuff] close which turns out to occur on some ppp type setups. This is a quick patch up for the problem. It's not really fixing Nozomi which completely fails to implement tty open/close semantics and all the other needed stuff. Doing it right is a rather more invasive patch set and not one that will backport. Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Erez Zadok authored
commit e27759d7 upstream. Ecryptfs_open dereferences a pointer to the private lower file (the one stored in the ecryptfs inode), without checking if the pointer is NULL. Right afterward, it initializes that pointer if it is NULL. Swap order of statements to first initialize. Bug discovered by Duckjin Kang. Signed-off-by:
Duckjin Kang <fromdj2k@gmail.com> Signed-off-by:
Erez Zadok <ezk@cs.sunysb.edu> Cc: Dustin Kirkland <kirkland@canonical.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Tyler Hicks <tyhicks@linux.vnet.ibm.com> Signed-off-by:
-
Dan Carpenter authored
commit ece550f5 upstream. The "full_alg_name" variable is used on a couple error paths, so we shouldn't free it until the end. Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
Greg Kroah-Hartman authored
commit 70362511 upstream. We need to keep the lock held over the call to __f_setown() to prevent a PID race. Thanks to Al Viro for pointing out the problem, and to Travis for making us look here in the first place. Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Al Viro <viro@ZenIV.linux.org.uk> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Tavis Ormandy <taviso@google.com> Cc: Jeff Dike <jdike@addtoit.com> Cc: Julien Tinnes <jln@google.com> Cc: Matt Mackall <mpm@selenic.com> Signed-off-by:
-
Greg Kroah-Hartman authored
commit 7692fd4d upstream. This fixes a number of SMP problems that were in the hyperv core code. Patch originally written by K. Y. Srinivasan <ksrinivasan@novell.com> but forward ported to the latest in-kernel code and tweaked slightly by me. Novell, Inc. hereby disclaims all copyright in any derivative work copyright associated with this patch. Signed-off-by:
K. Y. Srinivasan <ksrinivasan@novell.com> Cc: Hank Janssen <hjanssen@microsoft.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by:
-
Eugeni Dodonov authored
commit 20633bf0 upstream. After updating to 2.6.32 kernel, I started experiencing Oopses caused by the asus_oled module. After quick investigation, I wrapped this simple patch which fixes an Oops in by asus_oled module on 2.6.32.2 kernel, caused by incorrect usage of strict_strtoul function call within set_enabled and set_disabled functions. This can be triggered by simple running the userspace client for asus_old (e.g., 'asusoled -e' or 'asusoled -d'). Signed-off-by:
Eugeni Dodonov <eugeni@mandriva.com> Signed-off-by:
-
Jean-Francois Moine authored
commit 07d1c69b upstream. A previous code optimization inverted bridge registers and values, doing a regression in kernel 2.6.32. Signed-off-by:
Jean-Francois Moine <moinejf@free.fr> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
H. Peter Anvin authored
commit 0b962d47 upstream. register_chrdev() hardcodes registering 256 minors, presumably to avoid breaking old drivers. However, we need to register enough minors so that we have all possible CPUs. checkpatch warns on this patch, but the patch is correct: NR_CPUS here is a static *upper bound* on the *maximum CPU index* (not *number of CPUs!*) and that is what we want. Reported-and-tested-by:
Russ Anderson <rja@sgi.com> Cc: Tejun Heo <tj@kernel.org> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Takashi Iwai <tiwai@suse.de> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> LKML-Reference: <tip-*@git.kernel.org> Signed-off-by:
-
- 22 Jan, 2010 8 commits
-
-
Greg Kroah-Hartman authored
-
OGAWA Hirofumi authored
commit cedabed4 upstream. If __block_prepare_write() was failed in block_write_begin(), the allocated blocks can be outside of ->i_size. But new truncate_pagecache() in vmtuncate() does nothing if new < old. It means the above usage is not working anymore. So, this patch fixes it by removing "new < old" check. It would need more cleanup/change. But, now -rc and truncate working is in progress, so, this tried to fix it minimum change. Acked-by:
Nick Piggin <npiggin@suse.de> Signed-off-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by:
-
Peter Zijlstra authored
commit 57785df5 upstream. 83f9ac removed a call to effective_prio() in wake_up_new_task(), which leads to tasks running at MAX_PRIO. This is caused by the idle thread being set to MAX_PRIO before forking off init. O(1) used that to make sure idle was always preempted, CFS uses check_preempt_curr_idle() for that so we can savely remove this bit of legacy code. Reported-by:
Mike Galbraith <efault@gmx.de> Tested-by:
-
Ping authored
commit 3018aa4b upstream. This is a new two finger touch Fujitsu Wacom Tablet PC. Signed-off-by:
-
Wolfram Sang authored
commit 22f8b269 upstream. Unexpected signals can disturb the bus-handling and lock it up. Don't use interruptible in 'wait_event_*' and 'wake_*' as in commits dc1972d0 (for cpm), 1ab082d7 (for mpc), b7af349b (for omap). Signed-off-by:
Wolfram Sang <w.sang@pengutronix.de> Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
commit c5567521 upstream. dev_dbg outputs dev_name, which is released with device_unregister. This bug resulted in output like this: i2c Xy2�0: adapter [SMBus I801 adapter at 1880] unregistered The right output would be: i2c i2c-0: adapter [SMBus I801 adapter at 1880] unregistered Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Signed-off-by:
-
David S. Miller authored
[ Upstream commit e04ed38d ] For chips like Niagara2 that have true overflow indications in the %pcr (which we don't actually need and don't use) the interrupt signal persists until the overflow bits are cleared by an explicit %pcr write. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
David S. Miller authored
[ Upstream commit 8183e2b3 ] If perf events are active, we should not reset the %pcr to PCR_PIC_PRIV. That perf events code does the management. Signed-off-by:
-
