- 04 Feb, 2011 4 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6Linus Torvalds authored
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (27 commits) gpu/stub: fix acpi_video build error, fix stub kconfig dependencies drm/radeon/kms: dynamically allocate power state space drm/radeon/kms: fix s/r issues with bios scratch regs agp: ensure GART has an address before enabling it Revert "agp: AMD AGP is used on UP1100 & UP1500 alpha boxen" amd-k7-agp: remove non-x86 code drm/radeon/kms/evergreen: always set certain VGT regs at CP init drm/radeon/kms: add updated ib_execute function for evergreen drm/radeon: remove 0x4243 pci id drm/radeon/kms: Enable new pll calculation for avivo+ asics drm/radeon/kms: add new pll algo for avivo asics drm/radeon/kms: add pll debugging output drm/radeon/kms: switch back to min->max pll post divider iteration drm/radeon/kms: rv6xx+ thermal sensor fixes drm/nv50: fix display on 0x50 drm/nouveau: correctly pair hwmon_init and hwmon_fini drm/i915: Only bind to function 0 of the PCI device drm/i915: Suppress spurious vblank interrupts drm: Avoid leak of adjusted mode along quick set_mode paths drm: Simplify and defend later checks when disabling a crtc ...
-
Keith Packard authored
In drm_crtc_helper_set_config, instead of always forcing all outputs to DRM_MODE_DPMS_ON, only set them if the CRTC is actually getting a mode set, as any mode set will turn all outputs on. This fixes https://lkml.org/lkml/2011/1/24/457Signed-off-by:
Keith Packard <keithp@keithp.com> Cc: stable@kernel.org (2.6.37) Reported-and-tested-by:
Carlos R. Mafra <crmafra2@gmail.com> Tested-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Randy Dunlap authored
The comments under "config STUB_POULSBO" are close to correct, but they are not being followed. This patch updates them to reflect the requirements for THERMAL. This build error is caused by STUB_POULSBO selecting ACPI_VIDEO when ACPI_VIDEO's config requirements are not met. ERROR: "thermal_cooling_device_register" [drivers/acpi/video.ko] undefined! ERROR: "thermal_cooling_device_unregister" [drivers/acpi/video.ko] undefined! Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Tested-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
git://git.kernel.org/pub/scm/linux/kernel/git/hch/hfsplusLinus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hch/hfsplus: hfsplus: fix up a comparism in hfsplus_file_extend hfsplus: fix two memory leaks in wrapper.c hfsplus: do not leak buffer on error hfsplus: fix failed mount handling
-
- 03 Feb, 2011 36 commits
-
-
Alex Deucher authored
We previously used a static array, but some new systems had more states then we had array space, so dynamically allocate space based on the number of states in the vbios. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=33851Signed-off-by:
Alex Deucher <alexdeucher@gmail.com> Cc: stable@kernel.org Signed-off-by:
-
Alex Deucher authored
The accelerate mode bit gets checked by certain atom command tables to set up some register state. It needs to be clear when setting modes and set when not. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=26942Signed-off-by:
-
Stephen Kitt authored
Some BIOSs (eg. the AMI BIOS on the Asus P4P800 motherboard) don't initialise the GART address, and pcibios_assign_resources() can ignore it because it can be marked as a host bridge (see https://bugzilla.kernel.org/show_bug.cgi?id=24392#c5 for details). This was handled correctly up to 2.6.35, but the pci_enable_device() cleanup in 2.6.36 96576a9e ("agp: intel-agp: do not use PCI resources before pci_enable_device()") means that the kernel tries to enable the GART before assigning it an address; in such cases the GART overlaps with other device assignments and ends up being disabled. This patch fixes https://bugzilla.kernel.org/show_bug.cgi?id=24392 Note that I imagine efficeon-agp.c probably has the same problem, but I can't test that and I'd like to make sure this patch is suitable for -stable (since 2.6.36 and 2.6.37 are affected). Signed-off-by:
Stephen Kitt <steve@sk2.org> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Maciej Rutecki <maciej.rutecki@gmail.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Kulikov Vasiliy <segooon@gmail.com> Cc: Florian Mickler <florian@mickler.org> Cc: <stable@kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Matt Turner authored
This reverts commit f191f144. The AMD 751 and 761 chipsets are used on the UP1000, UP1100, and UP1500 OEM motherboards, but they neglect to do anything to make AGP work. According to Ivan Kokshaysky: There is quite fundamental conflict between the Alpha architecture and x86 AGP implementation - Alpha is entirely cache coherent by design, while x86 AGP is not (I mean native AGP DMA transactions, not a PCI over AGP). There are no such things as non-cacheable mappings or software support for cache flushing/invalidation on Alpha, so x86 AGP code won't work on Nautilus. So there's no point in allowing this driver to be configured on Alpha. Signed-off-by:
Matt Turner <mattst88@gmail.com> Signed-off-by:
-
Matt Turner authored
amd-k7-agp can't be built on Alpha anymore, so remove now unnecessary code. Signed-off-by:
-
Alex Deucher authored
These should be handled by the clear_state setup, but set them directly as well just to be sure. Signed-off-by:
-
Alex Deucher authored
Adds new packet to disable DX9 constant emulation. Signed-off-by:
-
Christoph Hellwig authored
Revert an incorrect hunk from commit b2837fcf, "hfsplus: %L-to-%ll, macro correction, and remove unneeded braces" revert a pointless change of comparism operation argument order, which turned out to not even be equivalent. Reported-by:
Joe Perches <joe@perches.com> Signed-off-by:
Christoph Hellwig <hch@tuxera.com>
-
Chuck Ebbert authored
Signed-Off-By:
Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Chuck Ebbert authored
Signed-Off-By:
-
Christoph Hellwig authored
Currently the error handling in hfsplus_fill_super is a mess, and can lead to accessing fields in the superblock that haven't been even set up yet. Fix this by making sure we do not set up sb->s_root until we have the mount fully set up, and before that do proper step by step unwinding instead of using hfsplus_put_super as a big hammer. Reported-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6Linus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6: [SCSI] libsas: fix runaway error handler problem [SCSI] fix incorrect value of SCSI_MAX_SG_CHAIN_SEGMENTS due to include file ordering [SCSI] arcmsr: Fix the issue of system hangup after commands timeout on ARC-1200 [SCSI] mpt2sas: fix Integrated Raid unsynced on shutdown problem [SCSI] mpt2sas: Kernel Panic during Large Topology discovery [SCSI] mpt2sas: Fix the race between broadcast asyn event and scsi command completion [SCSI] mpt2sas: Correct resizing calculation for max_queue_depth [SCSI] mpt2sas: fix internal device reset for older firmware prior to MPI Rev K [SCSI] mpt2sas: Fix device removal handshake for zoned devices
-
Suresh Siddha authored
Clearing the cpu in prev's mm_cpumask early will avoid the flush tlb IPI's while the cr3 is still pointing to the prev mm. And this window can lead to the possibility of bogus TLB fills resulting in strange failures. One such problematic scenario is mentioned below. T1. CPU-1 is context switching from mm1 to mm2 context and got a NMI etc between the point of clearing the cpu from the mm_cpumask(mm1) and before reloading the cr3 with the new mm2. T2. CPU-2 is tearing down a specific vma for mm1 and will proceed with flushing the TLB for mm1. It doesn't send the flush TLB to CPU-1 as it doesn't see that cpu listed in the mm_cpumask(mm1). T3. After the TLB flush is complete, CPU-2 goes ahead and frees the page-table pages associated with the removed vma mapping. T4. CPU-2 now allocates those freed page-table pages for something else. T5. As the CR3 and TLB caches for mm1 is still active on CPU-1, CPU-1 can potentially speculate and walk through the page-table caches and can insert new TLB entries. As the page-table pages are already freed and being used on CPU-2, this page walk can potentially insert a bogus global TLB entry depending on the (random) contents of the page that is being used on CPU-2. T6. This bogus TLB entry being global will be active across future CR3 changes and can result in weird memory corruption etc. To avoid this issue, for the prev mm that is handing over the cpu to another mm, clear the cpu from the mm_cpumask(prev) after the cr3 is changed. Marking it for -stable, though we haven't seen any reported failure that can be attributed to this. Signed-off-by:Suresh Siddha <suresh.b.siddha@intel.com> Acked-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infinibandLinus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband: RDMA: Update missed conversion of flush_scheduled_work() RDMA/ucma: Copy iWARP route information on queries RDMA/amso1100: Fix compile warnings RDMA/cxgb4: Set the correct device physical function for iWARP connections RDMA/cxgb4: Limit MAXBURST EQ context field to 256B IB/qib: Hold link for TX SERDES settings mlx4_core: Add ConnectX-3 device IDs
-
Linus Torvalds authored
Merge branch 'irq-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'irq-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: genirq: Prevent irq storm on migration
-
Linus Torvalds authored
Merge branch 'sched-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'sched-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: sched: Fix update_curr_rt() sched, docs: Update schedstats documentation to version 15
-
Linus Torvalds authored
Merge branch 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: perf: Fix reading in perf_event_read() watchdog: Don't change watchdog state on read of sysctl watchdog: Fix sysctl consistency watchdog: Fix broken nowatchdog logic perf: Fix Pentium4 raw event validation perf: Fix alloc_callchain_buffers()
-
Peter Zijlstra authored
cpu_stopper_thread() migration_cpu_stop() __migrate_task() deactivate_task() dequeue_task() dequeue_task_rq() update_curr_rt() Will call update_curr_rt() on rq->curr, which at that time is rq->stop. The problem is that rq->stop.prio matches an RT prio and thus falsely assumes its a rt_sched_class task. Reported-Debuged-Tested-Acked-by:Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> LKML-Reference: <new-submission> Cc: stable@kernel.org # .37 Signed-off-by:
-
Peter Zijlstra authored
It is quite possible for the event to have been disabled between perf_event_read() sending the IPI and the CPU servicing the IPI and calling __perf_event_read(), hence revalidate the state. Reported-by:
Stephane Eranian <eranian@google.com> Signed-off-by:
-
Boaz Harrosh authored
This reverts commit 115e19c5. Apparently setting inode->bdi to one's own sb->s_bdi stops VFS from sending *read-aheads*. This problem was bisected to this commit. A revert fixes it. I'll investigate farther why is this happening for the next Kernel, but for now a revert. I'm sending to stable@kernel.org as well, since it exists also in 2.6.37. 2.6.36 is good and does not have this patch. CC: Stable Tree <stable@kernel.org> Signed-off-by:
Boaz Harrosh <bharrosh@panasas.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6Linus Torvalds authored
* 'media_fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6: [media] fix saa7111 non-detection [media] rc/streamzap: fix reporting response times [media] mceusb: really fix remaining keybounce issues [media] rc: use time unit conversion macros correctly [media] rc/ir-lirc-codec: add back debug spew [media] ir-kbd-i2c: improve remote behavior with z8 behind usb [media] lirc_zilog: z8 on usb doesn't like back-to-back i2c_master_send [media] hdpvr: fix up i2c device registration [media] rc/mce: add mappings for missing keys [media] gspca - zc3xx: Discard the partial frames [media] gspca - zc3xx: Fix bad images with the sensor hv7131r [media] gspca - zc3xx: Bad delay when given by a table
-
git://git390.marist.edu/pub/scm/linux-2.6Linus Torvalds authored
* 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6: [S390] reset default for CONFIG_CHSC_SCH [S390] qdio: prevent compile warning under CONFIG_32BIT [S390] use asm-generic/cacheflush.h [S390] tlb: fix build error caused by THP [S390] missing sacf in uaccess [S390] pgtable_list corruption [S390] dasd: prevent panic with unresumed devices
-
Josef Bacik authored
Some filesystems don't deal well with being asked to map less than blocksize blocks (GFS2 for example). Since we are always mapping at least blocksize sections anyway, just make sure len is at least as big as a blocksize so we don't trip up any filesystems. Thanks, Signed-off-by:
Josef Bacik <josef@redhat.com> Cc: Steven Whitehouse <swhiteho@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Namhyung Kim authored
FMODE_EXEC is a constant type of fmode_t but was used with normal integer constants. This results in following warnings from sparse. Fix it using new macro __FMODE_EXEC. fs/exec.c:116:58: warning: restricted fmode_t degrades to integer fs/exec.c:689:58: warning: restricted fmode_t degrades to integer fs/fcntl.c:777:9: warning: restricted fmode_t degrades to integer Signed-off-by:
Namhyung Kim <namhyung@gmail.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Namhyung Kim authored
AND-ing FMODE_* constant with normal integer results in following sparse warnings. Fix it. fs/open.c:662:21: warning: restricted fmode_t degrades to integer fs/anon_inodes.c:123:34: warning: restricted fmode_t degrades to integer Signed-off-by:
-
KAMEZAWA Hiroyuki authored
Changes in e401f176 ("memcg: modify accounting function for supporting THP better") adds nr_pages to support multiple page size in memory_cgroup_charge_statistics. But counting the number of event nees abs(nr_pages) for increasing counters. This patch fixes event counting. Signed-off-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Reviewed-by:
Johannes Weiner <hannes@cmpxchg.org> Cc: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> Cc: Balbir Singh <balbir@in.ibm.com> Cc: Minchan Kim <minchan.kim@gmail.com> Signed-off-by:
-
Johannes Weiner authored
Huge page coverage should obviously have less priority than the continued execution of a process. Never kill a process when charging it a huge page fails. Instead, give up after the first failed reclaim attempt and fall back to regular pages. Signed-off-by:
Minchan Kim <minchan.kim@gmail.com> Cc: Balbir Singh <balbir@linux.vnet.ibm.com> Cc: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> Signed-off-by:
-
Johannes Weiner authored
If reclaim after a failed charging was unsuccessful, the limits are checked again, just in case they settled by means of other tasks. This is all fine as long as every charge is of size PAGE_SIZE, because in that case, being below the limit means having at least PAGE_SIZE bytes available. But with transparent huge pages, we may end up in an endless loop where charging and reclaim fail, but we keep going because the limits are not yet exceeded, although not allowing for a huge page. Fix this up by explicitely checking for enough room, not just whether we are within limits. Signed-off-by:
-
Johannes Weiner authored
The charging code can encounter a charge size that is bigger than a regular page in two situations: one is a batched charge to fill the per-cpu stocks, the other is a huge page charge. This code is distributed over two functions, however, and only the outer one is aware of huge pages. In case the charging fails, the inner function will tell the outer function to retry if the charge size is bigger than regular pages--assuming batched charging is the only case. And the outer function will retry forever charging a huge page. This patch makes sure the inner function can distinguish between batch charging and a single huge page charge. It will only signal another attempt if batch charging failed, and go into regular reclaim when it is called on behalf of a huge page. Signed-off-by:
-
Jin Dongming authored
When a tail page of THP is poisoned, memory-failure will do nothing except setting PG_hwpoison, while the expected behavior is that the process, who is using the poisoned tail page, should be killed. The above problem is caused by lru check of the poisoned tail page of THP. Because PG_lru flag is only set on the head page of THP, the check always consider the poisoned tail page as NON lru page. So the lru check for the tail page of THP should be avoided, as like as hugetlb. This patch adds !PageTransCompound() before lru check for THP, because of the check (!PageHuge() && !PageTransCompound()) the whole branch could be optimized away at build time when both hugetlbfs and THP are set with "N" (or in archs not supporting either of those). [akpm@linux-foundation.org: fix unrelated typo in shake_page() comment] Signed-off-by:
Jin Dongming <jin.dongming@np.css.fujitsu.com> Reviewed-by:
Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Andi Kleen <andi@firstfloor.org> Signed-off-by:
-
Jin Dongming authored
When the tail page of THP is poisoned, the head page will be poisoned too. And the wrong address, address of head page, will be sent with sigbus always. So when the poisoned page is used by Guest OS which is running on KVM, after the address changing(hva->gpa) by qemu, the unexpected process on Guest OS will be killed by sigbus. What we expected is that the process using the poisoned tail page could be killed on Guest OS, but not that the process using the healthy head page is killed. Since it is not good to poison the healthy page, avoid poisoning other than the page which is really poisoned. (While we poison all pages in a huge page in case of hugetlb, we can do this for THP thanks to split_huge_page().) Here we fix two parts: 1. Isolate the poisoned page only to make sure the reported address is the address of poisoned page. 2. make the poisoned page work as the poisoned regular page. [akpm@linux-foundation.org: fix spello in comment] Signed-off-by: -
Jin Dongming authored
The poisoned THP is now split with split_huge_page() in collect_procs_anon(). If kmalloc() is failed in collect_procs(), split_huge_page() could not be called. And the work after split_huge_page() for collecting the processes using poisoned page will not be done, too. So the processes using the poisoned page could not be killed. The condition becomes worse when CONFIG_DEBUG_VM == "Y". Because the poisoned THP could not be split, system panic will be caused by VM_BUG_ON(PageTransHuge(page)) in try_to_unmap(). This patch does: 1. move split_huge_page() to the place before collect_procs(). This can be sure the failure of splitting THP is caused by itself. 2. when splitting THP is failed, stop the operations after it. This can avoid unexpected system panic or non sense works. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: -
Ben Dooks authored
The support@simtec.co.uk address is for direct customer support only, the EB2410ITX and EB110ATX entries should direct to the Simtec Linux Team address of linux@simtec.co.uk Also add correct email address for Vincent Sanders [akpm@linux-foundation.org: fix Vincent's address] Signed-off-by:
Ben Dooks <ben-linux@fluff.org> Cc: Vincent Sanders <vince@simtec.co.uk> Cc: Simtec Support <support@simtec.co.uk> Cc: Simtec Linux Team <linux@simtec.co.uk> Cc: Jack Stone <jwjstone@fastmail.fm> Signed-off-by:
-
Ben Dooks authored
Add the correct files for the Simtec BAST machine, ensuring the IDE and IRQ routing are added, and move to the machine specific file instead of trying to catch all of arch/arm/mach-s3c2410 Signed-off-by:
-
Ben Dooks authored
There are currently two entries under the "SIMTEC EB2410ITX (BAST)" machine entry for drivers/*/*s3c2410*, which is catching everything s3c2410 driver related. This entry is for a specific S3C2410 based machine, so move these two file entries to the "ARM/SAMSUNG ARM ARCHITECTURES" entry, where it will reach a wider audience of interested parties. Signed-off-by:
Kukjin Kim <kgene.kim@samsung.com> Cc: Jack Stone <jwjstone@fastmail.fm> Signed-off-by:
-
Eric Dumazet authored
commit 95aac7b1 ("epoll: make epoll_wait() use the hrtimer range feature") added a performance regression because it uses timespec_add_ns() with potential very large 'ns' values. [akpm@linux-foundation.org: s/epoll_set_mstimeout/ep_set_mstimeout/, per Davide] Reported-by:
Simon Kirby <sim@hostway.ca> Signed-off-by:
Eric Dumazet <eric.dumazet@gmail.com> Cc: Shawn Bohrer <shawn.bohrer@gmail.com> Acked-by:
Davide Libenzi <davidel@xmailserver.org> Cc: <stable@kernel.org> [2.6.37.x] Signed-off-by:
-
