- 04 Oct, 2011 8 commits
-
-
git://git.secretlab.ca/git/linux-2.6Linus Torvalds authored
* 'spi/merge' of git://git.secretlab.ca/git/linux-2.6: spi-topcliff-pch: Fix overrun issue spi-topcliff-pch: Add recovery processing in case FIFO overrun error occurs spi-topcliff-pch: Fix CPU read complete condition issue spi-topcliff-pch: Fix SSN Control issue spi-topcliff-pch: add tx-memory clear after complete transmitting
-
Jon Mason authored
Add the ability to disable PCI-E MPS turning and using the BIOS configured MPS defaults. Due to the number of issues recently discovered on some x86 chipsets, make this the default behavior. Also, add the option for peer to peer DMA MPS configuration. Peer to peer DMA is outside the scope of this patch, but MPS configuration could prevent it from working by having the MPS on one root port different than the MPS on another. To work around this, simply make the system wide MPS the smallest possible value (128B). Signed-off-by: Jon Mason <mason@myri.com> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Tomoya MORINAGA authored
We found that adding load, Rx data sometimes drops.(with DMA transfer mode) The cause is that before starting Rx-DMA processing, Tx-DMA processing starts. This causes FIFO overrun occurs. This patch fixes the issue by modifying FIFO tx-threshold and DMA descriptor size like below. Current this patch Rx-descriptor 4Byte+12Byte*341 --> 12Byte*340-4Byte-12Byte Rx-threshold (Not modified) Tx-descriptor 4Byte+12Byte*341 --> 16Byte-12Byte*340 Rx-threshold 12Byte --> 2Byte Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
-
Tomoya MORINAGA authored
Add recovery processing in case FIFO overrun error occurs with DMA transfer mode. Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
-
Tomoya MORINAGA authored
We found Rx data sometimes drops.(with non-DMA transfer mode) The cause is read complete condition is not true. This patch fixes the issue. Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
-
Tomoya MORINAGA authored
During processing 1 command/data series, SSN should keep LOW. However, currently, SSN becomes HIGH. This patch fixes the issue. Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
-
Tomoya MORINAGA authored
Currently, in case of reading date from SPI flash, command is sent twice. The cause is that tx-memory clear processing is missing . This patch adds the tx-momory clear processing. Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
-
Takashi Iwai authored
Commit 2a7fade7 ("hwmon: lis3: Power on corrections") caused a regression on HP laptops with 8bit chip. Writing CTRL2_BOOT_8B bit seems clearing the BIOS setup, and no proper interrupt for DriveGuard will be triggered any more. Since the init code there is basically only for embedded devices, put a pdata check so that the problematic initialization will be skipped for hp_accel stuff. Signed-off-by: Takashi Iwai <tiwai@suse.de> Cc: Eric Piel <eric.piel@tremplin-utc.net> Cc: Samu Onkalo <samu.p.onkalo@nokia.com> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@google.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
- 03 Oct, 2011 6 commits
-
-
git://github.com/groeck/linuxLinus Torvalds authored
* 'hwmon-for-linus' of git://github.com/groeck/linux: hwmon: (coretemp) Avoid leaving around dangling pointer hwmon: (coretemp) Fixup platform device ID change
-
git://github.com/davem330/ideLinus Torvalds authored
* git://github.com/davem330/ide: ide-disk: Fix request requeuing
-
git://github.com/chrismason/linuxLinus Torvalds authored
* 'btrfs-3.0' of git://github.com/chrismason/linux: Btrfs: force a page fault if we have a shorty copy on a page boundary
-
Borislav Petkov authored
Simon Kirby reported that on his RAID setup with idedisk underneath the box OOMs after a couple of days of runtime. Running with CONFIG_DEBUG_KMEMLEAK pointed to idedisk_prep_fn() which unconditionally allocates an ide_cmd struct. However, ide_requeue_and_plug() can be called more than once per request, either from the request issue or the IRQ handler path and do blk_peek_request() ends up in idedisk_prep_fn() repeatedly, allocating a struct ide_cmd everytime and "forgetting" the previous pointer. Make sure the code reuses the old allocated chunk. Reported-and-tested-by: Simon Kirby <sim@hostway.ca> Cc: <stable@kernel.org> [ 39.x, 3.0.x ] Link: http://marc.info/?l=linux-kernel&m=131667641517919 Link: http://lkml.kernel.org/r/20110922072643.GA27232@hostway.caSigned-off-by: Borislav Petkov <bp@alien8.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
git://git.infradead.org/users/sameo/mfd-2.6Linus Torvalds authored
* 'for-linus' of git://git.infradead.org/users/sameo/mfd-2.6: mfd: Fix generic irq chip ack function name for jz4740-adc
-
git://github.com/tiwai/soundLinus Torvalds authored
* 'for-linus' of git://github.com/tiwai/sound: ALSA: hda - Fix a regression of the position-buffer check
-
- 02 Oct, 2011 1 commit
-
-
git://tesla.tglx.de/git/linux-2.6-tipLinus Torvalds authored
* 'perf-urgent-for-linus' of git://tesla.tglx.de/git/linux-2.6-tip: perf tools: Fix raw sample reading
-
- 01 Oct, 2011 1 commit
-
-
Linus Torvalds authored
Merge branches 'irq-urgent-for-linus', 'x86-urgent-for-linus' and 'sched-urgent-for-linus' of git://tesla.tglx.de/git/linux-2.6-tip * 'irq-urgent-for-linus' of git://tesla.tglx.de/git/linux-2.6-tip: irq: Fix check for already initialized irq_domain in irq_domain_add irq: Add declaration of irq_domain_simple_ops to irqdomain.h * 'x86-urgent-for-linus' of git://tesla.tglx.de/git/linux-2.6-tip: x86/rtc: Don't recursively acquire rtc_lock * 'sched-urgent-for-linus' of git://tesla.tglx.de/git/linux-2.6-tip: posix-cpu-timers: Cure SMP wobbles sched: Fix up wchan borkage sched/rt: Migrate equal priority tasks to available CPUs
-
- 30 Sep, 2011 12 commits
-
-
Josef Bacik authored
A user reported a problem where ceph was getting into 100% cpu usage while doing some writing. It turns out it's because we were doing a short write on a not uptodate page, which means we'd fall back at one page at a time and fault the page in. The problem is our position is on the page boundary, so our fault in logic wasn't actually reading the page, so we'd just spin forever or until the page got read in by somebody else. This will force a readpage if we end up doing a short copy. Alexandre could reproduce this easily with ceph and reports it fixes his problem. I also wrote a reproducer that no longer hangs my box with this patch. Thanks, Reported-and-tested-by: Alexandre Oliva <aoliva@redhat.com> Signed-off-by: Josef Bacik <josef@redhat.com> Signed-off-by: Chris Mason <chris.mason@oracle.com>
-
git://github.com/acmel/linuxIngo Molnar authored
-
Peter Zijlstra authored
David reported: Attached below is a watered-down version of rt/tst-cpuclock2.c from GLIBC. Just build it with "gcc -o test test.c -lpthread -lrt" or similar. Run it several times, and you will see cases where the main thread will measure a process clock difference before and after the nanosleep which is smaller than the cpu-burner thread's individual thread clock difference. This doesn't make any sense since the cpu-burner thread is part of the top-level process's thread group. I've reproduced this on both x86-64 and sparc64 (using both 32-bit and 64-bit binaries). For example: [davem@boricha build-x86_64-linux]$ ./test process: before(0.001221967) after(0.498624371) diff(497402404) thread: before(0.000081692) after(0.498316431) diff(498234739) self: before(0.001223521) after(0.001240219) diff(16698) [davem@boricha build-x86_64-linux]$ The diff of 'process' should always be >= the diff of 'thread'. I make sure to wrap the 'thread' clock measurements the most tightly around the nanosleep() call, and that the 'process' clock measurements are the outer-most ones. --- #include <unistd.h> #include <stdio.h> #include <stdlib.h> #include <time.h> #include <fcntl.h> #include <string.h> #include <errno.h> #include <pthread.h> static pthread_barrier_t barrier; static void *chew_cpu(void *arg) { pthread_barrier_wait(&barrier); while (1) __asm__ __volatile__("" : : : "memory"); return NULL; } int main(void) { clockid_t process_clock, my_thread_clock, th_clock; struct timespec process_before, process_after; struct timespec me_before, me_after; struct timespec th_before, th_after; struct timespec sleeptime; unsigned long diff; pthread_t th; int err; err = clock_getcpuclockid(0, &process_clock); if (err) return 1; err = pthread_getcpuclockid(pthread_self(), &my_thread_clock); if (err) return 1; pthread_barrier_init(&barrier, NULL, 2); err = pthread_create(&th, NULL, chew_cpu, NULL); if (err) return 1; err = pthread_getcpuclockid(th, &th_clock); if (err) return 1; pthread_barrier_wait(&barrier); err = clock_gettime(process_clock, &process_before); if (err) return 1; err = clock_gettime(my_thread_clock, &me_before); if (err) return 1; err = clock_gettime(th_clock, &th_before); if (err) return 1; sleeptime.tv_sec = 0; sleeptime.tv_nsec = 500000000; nanosleep(&sleeptime, NULL); err = clock_gettime(th_clock, &th_after); if (err) return 1; err = clock_gettime(my_thread_clock, &me_after); if (err) return 1; err = clock_gettime(process_clock, &process_after); if (err) return 1; diff = process_after.tv_nsec - process_before.tv_nsec; printf("process: before(%lu.%.9lu) after(%lu.%.9lu) diff(%lu)\n", process_before.tv_sec, process_before.tv_nsec, process_after.tv_sec, process_after.tv_nsec, diff); diff = th_after.tv_nsec - th_before.tv_nsec; printf("thread: before(%lu.%.9lu) after(%lu.%.9lu) diff(%lu)\n", th_before.tv_sec, th_before.tv_nsec, th_after.tv_sec, th_after.tv_nsec, diff); diff = me_after.tv_nsec - me_before.tv_nsec; printf("self: before(%lu.%.9lu) after(%lu.%.9lu) diff(%lu)\n", me_before.tv_sec, me_before.tv_nsec, me_after.tv_sec, me_after.tv_nsec, diff); return 0; } This is due to us using p->se.sum_exec_runtime in thread_group_cputime() where we iterate the thread group and sum all data. This does not take time since the last schedule operation (tick or otherwise) into account. We can cure this by using task_sched_runtime() at the cost of having to take locks. This also means we can (and must) do away with thread_group_sched_runtime() since the modified thread_group_cputime() is now more accurate and would deadlock when called from thread_group_sched_runtime(). Aside of that it makes the function safe on 32 bit systems. The old code added t->se.sum_exec_runtime unprotected. sum_exec_runtime is a 64bit value and could be changed on another cpu at the same time. Reported-by: David Miller <davem@davemloft.net> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: stable@kernel.org Link: http://lkml.kernel.org/r/1314874459.7945.22.camel@twinsTested-by: David Miller <davem@davemloft.net> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
-
Takashi Iwai authored
The commit a810364a ALSA: hda - Handle -1 as invalid position, too caused a regression on some machines that require the position-buffer instead of LPIB, e.g. resulting in noises with mic recording with PulseAudio. This patch fixes the detection by delaying the test at the timing as same as 3.0, i.e. doing the position check only when requested in azx_position_ok(). Reported-and-tested-by: Rocko Requin <rockorequin@hotmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Ram Pai authored
__find_resource() incorrectly returns a resource window which overlaps an existing allocated window. This happens when the parent's resource-window spans 0x00000000 to 0xffffffff and is entirely allocated to all its children resource-windows. __find_resource() looks for gaps in resource allocation among the children resource windows. When it encounters the last child window it blindly tries the range next to one allocated to the last child. Since the last child's window ends at 0xffffffff the calculation overflows, leading the algorithm to believe that any window in the range 0x0000000 to 0xfffffff is available for allocation. This leads to a conflicting window allocation. Michal Ludvig reported this issue seen on his platform. The following patch fixes the problem and has been verified by Michal. I believe this bug has been there for ages. It got exposed by git commit 2bbc6942 ("PCI : ability to relocate assigned pci-resources") Signed-off-by: Ram Pai <linuxram@us.ibm.com> Tested-by: Michal Ludvig <mludvig@logix.net.nz> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
git://github.com/NewDreamNetwork/ceph-clientLinus Torvalds authored
* 'for-linus' of git://github.com/NewDreamNetwork/ceph-client: libceph: fix pg_temp mapping update libceph: fix pg_temp mapping calculation libceph: fix linger request requeuing libceph: fix parse options memory leak libceph: initialize ack_stamp to avoid unnecessary connection reset
-
git://linuxtv.org/mchehab/for_linusLinus Torvalds authored
* 'v4l_for_linus' of git://linuxtv.org/mchehab/for_linus: [media] omap3isp: Fix build error in ispccdc.c [media] uvcvideo: Fix crash when linking entities [media] v4l: Make sure we hold a reference to the v4l2_device before using it [media] v4l: Fix use-after-free case in v4l2_device_release [media] uvcvideo: Set alternate setting 0 on resume if the bus has been reset [media] OMAP_VOUT: Fix build break caused by update_mode removal in DSS2
-
git://git390.marist.edu/pub/scm/linux-2.6Linus Torvalds authored
* 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6: [S390] cio: fix cio_tpi ignoring adapter interrupts [S390] gmap: always up mmap_sem properly [S390] Do not clobber personality flags on exec
-
git://github.com/davem330/sparcLinus Torvalds authored
* git://github.com/davem330/sparc: sparc64: Force the execute bit in OpenFirmware's translation entries. sparc: Make '-p' boot option meaningful again. sparc, exec: remove redundant addr_limit assignment sparc64: Future proof Niagara cpu detection.
-
git://people.freedesktop.org/~keithp/linuxLinus Torvalds authored
* 'drm-intel-fixes' of git://people.freedesktop.org/~keithp/linux: drm/i915: FBC off for ironlake and older, otherwise on by default drm/i915: Enable SDVO hotplug interrupts for HDMI and DVI drm/i915: Enable dither whenever display bpc < frame buffer bpc
-
Benjamin Herrenschmidt authored
Apple Quad G5 has some oddity in it's device-tree which causes the new generic matching code to fail to relate nodes for PCI-E devices below U4 with their respective struct pci_dev. This breaks graphics on those machines among others. This fixes it using a quirk which copies the node pointer from the host bridge for the root complex, which makes the generic code work for the children afterward. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
wangyanqing authored
Commit d5767c53 ("bootup: move 'usermodehelper_enable()' to the end of do_basic_setup()") moved 'usermodehelper_enable()' to end of do_basic_setup() to after the initcalls. But then I get failed to let uvesafb work on my computer, and lose the splash boot. So maybe we could start usermodehelper_enable a little early to make some task work that need eary init with the help of user mode. [ I would *really* prefer that initcalls not call into user space - even the real 'init' hasn't been execve'd yet, after all! But for uvesafb it really does look like we don't have much choice. I considered doing this when we mount the root filesystem, but depending on config options that is in multiple places. We could do the usermode helper enable as a rootfs_initcall().. So I'm just using wang yanqing's trivial patch. It's not wonderful, but it's simple and should work. We should revisit this some day, though. - Linus ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
- 29 Sep, 2011 2 commits
-
-
Jiri Olsa authored
Wrong pointer is being passed for raw data sanity checking, when parsing sample event. This ends up with invalid event and perf record being stuck in __perf_session__process_events function during processing build IDs (process_buildids function). Following command hangs up in my setup: ./perf record -e raw_syscalls:sys_enter ls The fix is to use proper pointer to the raw data instead of the 'u' union. Reviewed-by: David Ahern <dsahern@gmail.com> Cc: David Ahern <dsahern@gmail.com> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Neil Horman <nhorman@tuxdriver.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Steven Rostedt <rostedt@goodmis.org> Link: http://lkml.kernel.org/r/1317308709-9474-2-git-send-email-jolsa@redhat.comSigned-off-by: Jiri Olsa <jolsa@redhat.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
David S. Miller authored
In the OF 'translations' property, the template TTEs in the mappings never specify the executable bit. This is the case even though some of these mappings are for OF's code segment. Therefore, we need to force the execute bit on in every mapping. This problem can only really trigger on Niagara/sun4v machines and the history behind this is a little complicated. Previous to sun4v, the sun4u TTE entries lacked a hardware execute permission bit. So OF didn't have to ever worry about setting anything to handle executable pages. Any valid TTE loaded into the I-TLB would be respected by the chip. But sun4v Niagara chips have a real hardware enforced executable bit in their TTEs. So it has to be set or else the I-TLB throws an instruction access exception with type code 6 (protection violation). We've been extremely fortunate to not get bitten by this in the past. The best I can tell is that the OF's mappings for it's executable code were mapped using permanent locked mappings on sun4v in the past. Therefore, the fact that we didn't have the exec bit set in the OF translations we would use did not matter in practice. Thanks to Greg Onufer for helping me track this down. Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 28 Sep, 2011 10 commits
-
-
Linus Torvalds authored
Doing it just before starting to call into cpu_idle() made a sick kind of sense only because the original bug we fixed (see commit 288d5abe: "Boot up with usermodehelper disabled") was about problems with some scheduler data structures not being initialized, and they had better be initialized at that point. But it really didn't make any other conceptual sense, and doing it after the initial "schedule()" call for the idle thread actually opened up a race: what if the main initialization thread did everything without needing to sleep, and got all the way into user land too? Without actually having scheduled back to the idle thread? Now, in normal circumstances that doesn't ever happen, but it looks like Richard Cochran triggered exactly that on his ARM IXP4xx machines: "I have some ARM IXP4xx based machines that use the two on chip MAC ports (aka NPEs). The NPE needs a firmware in order to function. Ever since the following commit [that 288d5abe one], it is no longer possible to bring up the interfaces during the init scripts." with a call trace showing an ioctl coming from user space. Richard says: "The init is busybox, and the startup script does mount, syslogd, and then ifup, so that all can go by quickly." The fix is to move the usermodehelper_enable() into the main 'init' thread, and just put it after we've done all our initcalls. By then, everything really should be up, but we've obviously not actually started the user-mode portion of init yet. Reported-and-tested-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Sage Weil authored
The incremental map updates have a record for each pg_temp mapping that is to be add/updated (len > 0) or removed (len == 0). The old code was written as if the updates were a complete enumeration; that was just wrong. Update the code to remove 0-length entries and drop the rbtree traversal. This avoids misdirected (and hung) requests that manifest as server errors like [WRN] client4104 10.0.1.219:0/275025290 misdirected client4104.1:129 0.1 to osd0 not [1,0] in e11/11 Signed-off-by: Sage Weil <sage@newdream.net>
-
Sage Weil authored
We need to apply the modulo pg_num calculation before looking up a pgid in the pg_temp mapping rbtree. This fixes pg_temp mappings, and fixes (some) misdirected requests that result in messages like [WRN] client4104 10.0.1.219:0/275025290 misdirected client4104.1:129 0.1 to osd0 not [1,0] in e11/11 on the server and stall make the client block without getting a reply (at least until the pg_temp mapping goes way, but that can take a long long time). Reorder calc_pg_raw() a bit to make more sense. Signed-off-by: Sage Weil <sage@newdream.net>
-
git://github.com/davem330/netLinus Torvalds authored
* git://github.com/davem330/net: ipv6-multicast: Fix memory leak in IPv6 multicast. ipv6: check return value for dst_alloc net: check return value for dst_alloc ipv6-multicast: Fix memory leak in input path. bnx2x: add missing break in bnx2x_dcbnl_get_cap bnx2x: fix WOL by enablement PME in config space bnx2x: fix hw attention handling net: fix a typo in Documentation/networking/scaling.txt ath9k: Fix a dma warning/memory leak rtlwifi: rtl8192cu: Fix unitialized struct iwlagn: fix dangling scan request batman-adv: do_bcast has to be true for broadcast packets only cfg80211: Fix validation of AKM suites iwlegacy: do not use interruptible waits iwlegacy: fix command queue timeout ath9k_hw: Fix Rx DMA stuck for AR9003 chips
-
git://bedivere.hansenpartnership.com/git/scsi-rc-fixes-2.6Linus Torvalds authored
* git://bedivere.hansenpartnership.com/git/scsi-rc-fixes-2.6: [SCSI] 3w-9xxx: fix iommu_iova leak [SCSI] cxgb3i: convert cdev->l2opt to use rcu to prevent NULL dereference [SCSI] scsi: qla4xxx needs libiscsi.o [SCSI] libsas: fix failure to revalidate domain for anything but the first expander child. [SCSI] aacraid: reset should disable MSI interrupt
-
Guenter Roeck authored
Storing the struct temp_data pointer allocated from create_core_data() when returning an error has the potential of leaving around a pointer to freed memory. Reset it to NULL for error returns. Reported-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com> Acked-by: Jean Delvare <khali@linux-fr.org>
-
Jean Delvare authored
With recent change "hwmon: (coretemp) don't use kernel assigned CPU number as platform device ID", the microcode check is now running on random CPU. Fix that by checking the microcode before creating the platform device rather than at probe time. Also avoid calling TO_PHYS_ID(cpu) twice in the same function, it's expensive. Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Jan Beulich <jbeulich@suse.com> Cc: Guenter Roeck <guenter.roeck@ericsson.com> Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
-
git://git.kernel.dk/linux-blockLinus Torvalds authored
* 'for-linus' of git://git.kernel.dk/linux-block: block: Free queue resources at blk_release_queue()
-
git://github.com/fengguang/linuxLinus Torvalds authored
* 'writeback-for-linus' of git://github.com/fengguang/linux: writeback: show raw dirtied_when in trace writeback_single_inode
-
Hannes Reinecke authored
A kernel crash is observed when a mounted ext3/ext4 filesystem is physically removed. The problem is that blk_cleanup_queue() frees up some resources eg by calling elevator_exit(), which are not checked for in normal operation. So we should rather move these calls to the destructor function blk_release_queue() as at that point all remaining references are gone. However, in doing so we have to ensure that any externally supplied queue_lock is disconnected as the driver might free up the lock after the call of blk_cleanup_queue(), Signed-off-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
-