- 06 Jan, 2010 10 commits
-
-
Bartlomiej Zolnierkiewicz authored
commit 509426bd upstream. adev->dma_mode stores the transfer mode value not UDMA mode number so the condition in cmd64x_set_dmamode() is always true and the higher UDMA clock is always selected. This can potentially result in data corruption when UDMA33 device is used, when 40-wire cable is used or when the error recovery code decides to lower the device speed down. The issue was introduced in the commit 6a40da02 ("libata cmd64x: whack into a shape that looks like the documentation") which goes back to kernel 2.6.20. Signed-off-by:
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Sergei Shtylyov authored
commit 256ace9b upstream. The clock turnaround code still doesn't work for several reasons: - 'USE_DPLL' flag in 'ap->host->private_data' is never initialized or updated, so the driver can only set the chip to the DPLL clock mode, not the PCI mode; - the driver doesn't serialize access to the channels depending on the current clock mode like the vendor drivers, so the clock turnaround is only executed "optionally", not always as it should be; - the wrong ports are written to when hpt3x2n_set_clock() is called for the secondary channel; - hpt3x2n_set_clock() can inadvertently enable the disabled channels when resetting the channel state machines. Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by:
-
Thomas Gleixner authored
commit bb6eddf7 upstream. Xiaotian Feng triggered a list corruption in the clock events list on CPU hotplug and debugged the root cause. If a CPU registers more than one per cpu clock event device, then only the active clock event device is removed on CPU_DEAD. The unused devices are kept in the clock events device list. On CPU up the clock event devices are registered again, which means that we list_add an already enqueued list_head. That results in list corruption. Resolve this by removing all devices which are associated to the dead CPU on CPU_DEAD. Reported-by:
Xiaotian Feng <dfeng@redhat.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Tested-by:
-
Peter Zijlstra authored
commit e4f42888 upstream. We should skip !SD_LOAD_BALANCE domains. Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Mike Galbraith <efault@gmx.de> LKML-Reference: <20091216170517.653578430@chello.nl> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Suresh Siddha authored
commit 45a94d7c upstream. xsave_cntxt_init() does something like: cpuid(0xd, ..); // find out what features FP/SSE/.. etc are supported xsetbv(); // enable the features known to OS cpuid(0xd, ..); // find out the size of the context for features enabled Depending on what features get enabled in xsetbv(), value of the cpuid.eax=0xd.ecx=0.ebx changes correspondingly (representing the size of the context that is enabled). As we don't have volatile keyword for native_cpuid(), gcc 4.1.2 optimizes away the second cpuid and the kernel continues to use the cpuid information obtained before xsetbv(), ultimately leading to kernel crash on processors supporting more state than the legacy FP/SSE. Add "volatile" for native_cpuid(). Signed-off-by:
Suresh Siddha <suresh.b.siddha@intel.com> LKML-Reference: <1261009542.2745.55.camel@sbs-t61.sc.intel.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Peter Zijlstra authored
commit e6c8fba7 upstream. Make sure not to access sched_fair fields before verifying it is indeed a sched_fair task. Signed-off-by:
-
Mike Christie authored
commit 48de68a4 upstream. If transport_class_register fails we should unregister any registered classes, or we will leak memory or other resources. I did a quick modprobe of scsi_transport_fc to test the patch. Signed-off-by:
Mike Christie <michaelc@cs.wisc.edu> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Signed-off-by:
-
FUJITA Tomonori authored
commit c982c368 upstream. dio transfer always resets mdata->page_order to zero. It breaks high-order pages previously allocated for non-dio transfer. This patches adds reserved_page_order to st_buffer structure to save page order for non-dio transfer. http://bugzilla.kernel.org/show_bug.cgi?id=14563 When enlarge_buffer() allocates 524288 from 0, st uses six-order page allocation. So mdata->page_order is 6 and frp_seg is 2. After that, if st uses dio, sgl_map_user_pages() sets mdata->page_order to 0 for st_do_scsi(). After that, when we call normalize_buffer(), it frees only free frp_seg * PAGE_SIZE (2 * 4096) though we should free frp_seg * PAGE_SIZE << 6 (2 * 4096 << 6). So we see buffer_size is set to 516096 (524288 - 8192). Reported-by:
Joachim Breuer <linux-kernel@jmbreuer.net> Tested-by:
Kai Makisara <kai.makisara@kolumbus.fi> Signed-off-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by:
-
Michael Reed authored
commit 1486400f upstream. Fix crash in qla2x00_fdmi_register() due to the dpc thread executing before the scsi host has been fully added. Unable to handle kernel NULL pointer dereference (address 00000000000001d0) qla2xxx_7_dpc[4140]: Oops 8813272891392 [1] Call Trace: [<a000000100016910>] show_stack+0x50/0xa0 sp=e00000b07c59f930 bsp=e00000b07c591400 [<a000000100017180>] show_regs+0x820/0x860 sp=e00000b07c59fb00 bsp=e00000b07c5913a0 [<a00000010003bd60>] die+0x1a0/0x2e0 sp=e00000b07c59fb00 bsp=e00000b07c591360 [<a0000001000681a0>] ia64_do_page_fault+0x8c0/0x9e0 sp=e00000b07c59fb00 bsp=e00000b07c591310 [<a00000010000c8e0>] ia64_native_leave_kernel+0x0/0x270 sp=e00000b07c59fb90 bsp=e00000b07c591310 [<a000000207197350>] qla2x00_fdmi_register+0x850/0xbe0 [qla2xxx] sp=e00000b07c59fd60 bsp=e00000b07c591290 [<a000000207171570>] qla2x00_configure_loop+0x1930/0x34c0 [qla2xxx] sp=e00000b07c59fd60 bsp=e00000b07c591128 [<a0000002071732b0>] qla2x00_loop_resync+0x1b0/0x2e0 [qla2xxx] sp=e00000b07c59fdf0 bsp=e00000b07c5910c0 [<a000000207166d40>] qla2x00_do_dpc+0x9a0/0xce0 [qla2xxx] sp=e00000b07c59fdf0 bsp=e00000b07c590fa0 [<a0000001000d5bb0>] kthread+0x110/0x140 sp=e00000b07c59fe00 bsp=e00000b07c590f68 [<a000000100014a30>] kernel_thread_helper+0xd0/0x100 sp=e00000b07c59fe30 bsp=e00000b07c590f40 [<a00000010000a4c0>] start_kernel_thread+0x20/0x40 sp=e00000b07c59fe30 bsp=e00000b07c590f40 crash> dis a000000207197350 0xa000000207197350 <qla2x00_fdmi_register+2128>: [MMI] ld1 r45=[r14];; crash> scsi_qla_host.host 0xe00000b058c73ff8 host = 0xe00000b058c73be0, crash> Scsi_Host.shost_data 0xe00000b058c73be0 shost_data = 0x0, <<<<<<<<<<< The fc_transport fc_* workqueue threads have yet to be created. crash> ps | grep _7 3891 2 2 e00000b075c80000 IN 0.0 0 0 [scsi_eh_7] 4140 2 3 e00000b07c590000 RU 0.0 0 0 [qla2xxx_7_dpc] The thread creating adding the Scsi_Host is blocked due to other activity in sysfs. crash> bt 3762 PID: 3762 TASK: e00000b071e70000 CPU: 3 COMMAND: "modprobe" #0 [BSP:e00000b071e71548] schedule at a000000100727e00 #1 [BSP:e00000b071e714c8] __mutex_lock_slowpath at a0000001007295a0 #2 [BSP:e00000b071e714a8] mutex_lock at a000000100729830 #3 [BSP:e00000b071e71478] sysfs_addrm_start at a0000001002584f0 #4 [BSP:e00000b071e71440] create_dir at a000000100259350 #5 [BSP:e00000b071e71410] sysfs_create_subdir at a000000100259510 #6 [BSP:e00000b071e713b0] internal_create_group at a00000010025c880 #7 [BSP:e00000b071e71388] sysfs_create_group at a00000010025cc50 #8 [BSP:e00000b071e71368] dpm_sysfs_add at a000000100425050 #9 [BSP:e00000b071e71310] device_add at a000000100417d90 #10 [BSP:e00000b071e712d8] scsi_add_host at a00000010045a380 #11 [BSP:e00000b071e71268] qla2x00_probe_one at a0000002071be950 #12 [BSP:e00000b071e71248] local_pci_probe at a00000010032e490 #13 [BSP:e00000b071e71218] pci_device_probe at a00000010032ecd0 #14 [BSP:e00000b071e711d8] driver_probe_device at a00000010041d480 #15 [BSP:e00000b071e711a8] __driver_attach at a00000010041d6e0 #16 [BSP:e00000b071e71170] bus_for_each_dev at a00000010041c240 #17 [BSP:e00000b071e71150] driver_attach at a00000010041d0a0 #18 [BSP:e00000b071e71108] bus_add_driver at a00000010041b080 #19 [BSP:e00000b071e710c0] driver_register at a00000010041dea0 #20 [BSP:e00000b071e71088] __pci_register_driver at a00000010032f610 #21 [BSP:e00000b071e71058] (unknown) at a000000207200270 #22 [BSP:e00000b071e71018] do_one_initcall at a00000010000a9c0 #23 [BSP:e00000b071e70f98] sys_init_module at a0000001000fef00 #24 [BSP:e00000b071e70f98] ia64_ret_from_syscall at a00000010000c740 So, it appears that qla2xxx dpc thread is moving forward before the scsi host has been completely added. This patch moves the setting of the init_done (and online) flag to after the call to scsi_add_host() to hold off the dpc thread. Found via large lun count testing using 2.6.31. Signed-off-by:
Michael Reed <mdr@sgi.com> Acked-by:
Giridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by:
-
Kleber Sacilotto de Souza authored
commit 99c965dd upstream. After commits c82f63e4 (PCI: check saved state before restore) and 4b77b0a2 (PCI: Clear saved_state after the state has been restored) PCI drivers are prevented from restoring the device standard configuration registers twice in a row. These changes introduced a regression on ipr EEH recovery. The ipr device driver saves the PCI state only during the device probe and restores it on ipr_reset_restore_cfg_space() during IOA resets. This behavior is causing the EEH recovery to fail after the second error detected, since the registers are not being restored. One possible solution would be saving the registers after restoring them. The problem with this approach is that while recovering from an EEH error if pci_save_state() results in an EEH error, the adapter/slot will be reset, and end up back in ipr_reset_restore_cfg_space(), but it won't have a valid saved state to restore, so pci_restore_state() will fail. The following patch introduces a workaround for this problem, hacking around the PCI API by setting pdev->state_saved = true before we do the restore. It fixes the EEH regression and prevents that we hit another EEH error during EEH recovery. [jejb: fix is a hack ... Jesse and Rafael will fix properly] Signed-off-by:
Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com> Acked-by:
Brian King <brking@linux.vnet.ibm.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
- 18 Dec, 2009 30 commits
-
-
Greg Kroah-Hartman authored
-
Luck, Tony authored
commit cd7bcf32 upstream. Needed for commit 2c992208 ("intel-iommu: Detect DMAR in hyperspace at probe time.) to build on IA64. Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
-
Paul Mackerras authored
commit 0f624e7e upstream. It is quite legitimate for CPUs to be numbered sparsely, meaning that it possible for an online CPU to have a number which is greater than the total count of possible CPUs. Currently find_get_context() has a sanity check on the cpu number where it checks it against num_possible_cpus(). This test can fail for a legitimate cpu number if the cpu_possible_mask is sparsely populated. This fixes the problem by checking the CPU number against nr_cpumask_bits instead, since that is the appropriate check to ensure that the cpu number is same to pass to cpu_isset() subsequently. Reported-by:
Michael Neuling <mikey@neuling.org> Signed-off-by:
Paul Mackerras <paulus@samba.org> Tested-by:
Peter Zijlstra <peterz@infradead.org> LKML-Reference: <20091215084032.GA18661@brick.ozlabs.ibm.com> Signed-off-by:
-
Jan Engelhardt authored
commit 7a922637 upstream. For both .33 and .32-stable. Signed-off-by:
Jan Engelhardt <jengelh@medozas.de> Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Chris Wright authored
commit 1672af11 upstream. We are seeing a bug when booting w/ iommu=pt with current upstream (bisect blames 19943b0e "intel-iommu: Unify hardware and software passthrough support). The issue is specific to this loop during identity map initialization of each device: domain_context_mapping_one(si_domain, ..., CONTEXT_TT_PASS_THROUGH) ... /* Skip top levels of page tables for * iommu which has less agaw than default. */ for (agaw = domain->agaw; agaw != iommu->agaw; agaw--) { pgd = phys_to_virt(dma_pte_addr(pgd)); if (!dma_pte_present(pgd)) { <------ failing here spin_unlock_irqrestore(&iommu->lock, flags); return -ENOMEM; } This box has 2 iommu's in it. The catchall iommu has MGAW == 48, and SAGAW == 4. The other iommu has MGAW == 39, SAGAW == 2. The device that's failing the above pgd test is the only device connected to the non-catchall iommu, which has a smaller address width than the domain default. This test is not necessary since the context is in PT mode and the ASR is ignored. Thanks to Don Dutile for discovering and debugging this one. Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
-
David Woodhouse authored
commit 44cd613c upstream. The hotplug notifier will call find_domain() to see if the device in question has been assigned an IOMMU domain. However, this should never be called for devices with a "dummy" domain, such as graphics devices when intel_iommu=igfx_off is set and the corresponding IOMMU isn't even initialised. If you do that, it'll oops as it dereferences the (-1) pointer. The notifier function should check iommu_no_mapping() for the device before doing anything else. Signed-off-by:
-
David Woodhouse authored
commit 5595b528 upstream. Some HP BIOSes report an RMRR region (a region which needs a 1:1 mapping in the IOMMU for a given device) which has an end address lower than its start address. Detect that and warn, rather than triggering the BUG() in dma_pte_clear_range(). Signed-off-by:
-
David Woodhouse authored
commit 6ecbf01c upstream. The BIOS errors where an IOMMU is reported either at zero or a bogus address are causing problems even when the IOMMU is disabled -- because interrupt remapping uses the same hardware. Ensure that the checks get applied for the interrupt remapping initialisation too. Signed-off-by:
-
Chris Wright authored
commit 2c992208 upstream. Many BIOSes will lie to us about the existence of an IOMMU, and claim that there is one at an address which actually returns all 0xFF. We need to detect this early, so that we know we don't have a viable IOMMU and can set up swiotlb before it's too late. Signed-off-by:
-
David Woodhouse authored
commit 2e16cfca upstream. Ever since jffs2_garbage_collect_metadata() was first half-written in February 2001, it's been broken on architectures where 'char' is signed. When garbage collecting a symlink with target length above 127, the payload length would end up negative, causing interesting and bad things to happen. Signed-off-by:
-
Simon Horman authored
commit 258c8893 upstream. Make sure that any otherwise uninitialised fields of usvc are zero. This has been obvserved to cause a problem whereby the port of fwmark services may end up as a non-zero value which causes scheduling of a destination server to fail for persisitent services. As observed by Deon van der Merwe <dvdm@truteq.co.za>. This fix suggested by Julian Anastasov <ja@ssi.bg>. For good measure also zero udest. Cc: Deon van der Merwe <dvdm@truteq.co.za> Acked-by:
Julian Anastasov <ja@ssi.bg> Signed-off-by:
Simon Horman <horms@verge.net.au> Signed-off-by:
-
Hugh Dickins authored
commit d99be1a8 upstream. When do_nonlinear_fault() realizes that the page table must have been corrupted for it to have been called, it does print_bad_pte() and returns ... VM_FAULT_OOM, which is hard to understand. It made some sense when I did it for 2.6.15, when do_page_fault() just killed the current process; but nowadays it lets the OOM killer decide who to kill - so page table corruption in one process would be liable to kill another. Change it to return VM_FAULT_SIGBUS instead: that doesn't guarantee that the process will be killed, but is good enough for such a rare abnormality, accompanied as it is by the "BUG: Bad page map" message. And recent HWPOISON work has copied that code into do_swap_page(), when it finds an impossible swap entry: fix that to VM_FAULT_SIGBUS too. Signed-off-by:
Hugh Dickins <hugh.dickins@tiscali.co.uk> Cc: Izik Eidus <ieidus@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Nick Piggin <npiggin@suse.de> Reviewed-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Rik van Riel <riel@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com> Cc: Andi Kleen <andi@firstfloor.org> Reviewed-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Reviewed-by:
Wu Fengguang <fengguang.wu@intel.com> Reviewed-by:
Minchan Kim <minchan.kim@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Zhenyu Wang authored
commit 1b3c7a47 upstream. In disable sequence, all output ports on PCH have to be disabled before PCH transcoder, but LVDS port was left always enabled. This one fixes that by disable LVDS port properly during pipe disable process, and resolved stability issue seen on Ironlake. Also move panel fitting disable time just after pipe disable to align with the spec. Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Zhenyu Wang authored
commit 103a196f upstream. PineView only has 2 ports for LVDS and CRT. Don't enable other ports for it. Cc: Shaohua Li <shaohua.li@intel.com> Signed-off-by:
-
Chris Wilson authored
commit d271817b upstream. In commit d2d9f232, the guard for a valid video mode was removed. This caused the regression: kernel crash during kms graphic boot on Intel GM4500 platform https://bugzilla.redhat.com/show_bug.cgi?id=540218 This patches changes the logic slightly not to rely on a coupled variable, but to just check whether the video_modes is valid before dereferencing. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Zhenyu Wang <zhenyu.z.wang@intel.com> [ickle: Actually reference the correct bug report] Acked-by:
-
Yong Wang authored
Upstream commit a2202aa2. On platforms where bios handles the thermal monitor interrupt, APIC_LVTTHMR on each logical CPU is programmed to generate a SMI and OS can't touch it. Unfortunately AP bringup sequence using INIT-SIPI-SIPI clear all the LVT entries except the mask bit. Essentially this results in all LVT entries including the thermal monitoring interrupt set to masked (clearing the bios programmed value for APIC_LVTTHMR). And this leads to kernel take over the thermal monitoring interrupt on AP's but not on BSP (leaving the bios programmed value only on BSP). As a result of this, we have seen system hangs when the thermal monitoring interrupt is generated. Fix this by reading the initial value of thermal LVT entry on BSP and if bios has taken over the control, then program the same value on all AP's and leave the thermal monitoring interrupt control on all the logical cpu's to the bios. Signed-off-by:
Yong Wang <yong.y.wang@intel.com> Reviewed-by:
-
Florian Fainelli authored
commit a3f92eea upstream. This patch converts bcm63xx_enet to uset get_sset_count like the other drivers do. Signed-off-by:
Florian Fainelli <ffainelli@freebox.fr> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Rafal Milecki authored
commit 518c8df7 upstream. Signed-off-by:
Rafal Milecki <zajec5@gmail.com> Signed-off-by:
Jean-Francois Moine <moinejf@free.fr> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Cc: Surbhi Palande <surbhi.palande@canonical.com> Signed-off-by:
-
Jan Kara authored
commit 68eb3db0 upstream. When ext3_write_begin fails after allocating some blocks or generic_perform_write fails to copy data to write, we truncate blocks already instantiated beyond i_size. Although these blocks were never inside i_size, we have to truncate pagecache of these blocks so that corresponding buffers get unmapped. Otherwise subsequent __block_prepare_write (called because we are retrying the write) will find the buffers mapped, not call ->get_block, and thus the page will be backed by already freed blocks leading to filesystem and data corruption. Reported-by:
James Y Knight <foom@fuhm.net> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Eric W. Biederman authored
commit d90a909e upstream. I received some bug reports about userspace programs having problems because after RTM_NEWLINK was received they could not immeidate access files under /proc/sys/net/ because they had not been registered yet. The problem was trivailly fixed by moving the userspace notification from rtnetlink_event to the end of register_netdevice. Signed-off-by:
Eric W. Biederman <ebiederm@aristanetworks.com> Cc: David Miller <davem@davemloft.net> Signed-off-by:
-
Zhao Yakui authored
commit 03a05ed1 upstream. Currently, ARB_DISABLE is a NOP on all of the recent Intel platforms. For such platforms, reduce contention on c3_lock by skipping the fake ARB_DISABLE. The cpu model id on one laptop is 14. If we disable ARB_DISABLE on this box, the box can't be booted correctly. But if we still enable ARB_DISABLE on this box, the box can be booted correctly. So we still use the ARB_DISABLE for the cpu which mode id is less than 0x0f. http://bugzilla.kernel.org/show_bug.cgi?id=14700Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Acked-by:
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
-
Tejun Heo authored
No matching upstream commit as it was resolved differently there. pcpu_get_vm_areas() is used only when dynamic percpu allocator is used by the architecture. In 2.6.32, ia64 doesn't use dynamic percpu allocator and has a macro which makes pcpu_get_vm_areas() buggy via local/global variable aliasing and triggers compile warning. The problem is fixed in upstream and ia64 uses dynamic percpu allocators, so the only left issue is inclusion of unnecessary code and compile warning on ia64 on 2.6.32. Don't build pcpu_get_vm_areas() if legacy percpu allocator is in use. Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
Jan Beulich <JBeulich@novell.com> Signed-off-by:
-
Corentin Chary authored
commit d951d4cc upstream. The light sensor disable brightness key and /sys/class/backlight/ control. There was a lot of report from users who didn't understand why they couldn't change their brightness, including: https://bugs.launchpad.net/bugs/222171 https://bugzilla.novell.com/show_bug.cgi?id=514747 http://bugzilla.kernel.org/show_bug.cgi?id=13671 http://bugzilla.kernel.org/show_bug.cgi?id=14432 Now the light sensor is disabled, and if the user want to enable it, the level should be ok. The funny thing is that comments where ok, not code. Cc: stable@kernel.org Cc: Thomas Renninger <trenn@suse.de> Cc: Peter Küppers <peter-mailbox@web.de> Cc: Michael Franzl <michaelfranzl@gmx.at> Cc: Ian Turner <vectro@vectro.org> Signed-off-by:
Corentin Chary <corentincj@iksaif.net> Signed-off-by:
-
Peter Feuerer authored
commit 36065746 upstream. Added new BIOS versions for following netbooks: Acer 1410, Gateway LT31, Packard Bell DOA150. As the Gateway LT31 machines have different register values for setting and checking the off-state, the "cmd_off" variable has been splitted up to "cmd_off" and "chk_off". Signed-off-by:
Peter Feuerer <peter@piie.net> Cc: Borislav Petkov <petkovbb@gmail.com> Cc: Andreas Mohr <andi@lisas.de> Signed-off-by:
-
Alan Cox authored
commit 8c651311 upstream. Regression caused in 2.6.23 and then despite repeated requests never fixed or dealt with (Petr promised to sort it in 2008 but seems to have forgotten). Enough is enough - remove the problem line that was added. If it upsets someone they've had two years to deal with it and at the very least it'll rattle their cage and wake them up. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=9709Signed-off-by:
Alan Cox <alan@linux.intel.com> Reported-by:
Damon <account@bugzilla.kernel.org.juxtaposition.net> Tested-by:
Ruud van Melick <rvm1974@raketnet.nl> Cc: Petr Vandrovec <VANDROVE@vc.cvut.cz> Cc: Pekka Enberg <penberg@cs.helsinki.fi> Cc: Paul A. Clarke <pc@us.ibm.com> Signed-off-by:
-
Zhu Yi authored
commit 52ce3e9a upstream. Add PCI .shutdown method so that we can disable the device during shutdown or reboot. Without this, the reboot doesn't work well on some platforms. This fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2124Tested-by:
pablo <pablolm2005@gmail.com> Signed-off-by:
Zhu Yi <yi.zhu@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Henrique de Moraes Holschuh authored
commit 208b996b upstream. Since the rfkill rework in 2.6.31, the driver is always resuming with the radios disabled. Change thinkpad-acpi to ask the firmware to resume with the radios in the last state. This fixes the Bluetooth and WWAN rfkill switches. Note that it means we respect the firmware's oddities. Should the user toggle the hardware rfkill switch on and off, it might cause the radios to resume enabled. UWB is an unknown quantity since it has nowhere the same level of firmware support (no control over state storage in NVRAM, for example), and might need further fixing. Testers welcome. This change fixes a regression from 2.6.30. Reported-by:
Jerone Young <jerone.young@canonical.com> Reported-by:
Ian Molton <ian.molton@collabora.co.uk> Signed-off-by:
Henrique de Moraes Holschuh <hmh@hmh.eng.br> Tested-by:
-
Henrique de Moraes Holschuh authored
commit a9f8eacc upstream. According to a report, the R50e wants EC-based brightness control, even if it uses an Intel GPU. The current driver default was reported to not work at all. This bug can be worked around by the "brightness_mode=3" module parameter. Change the default of the R50e and R51 2xxx models (which use the same EC firmware, 1V) to TPACPI_BRGHT_Q_EC, but keep TPACPI_BRGHT_Q_ASK set for now, as I'd like to get more reports. This fixes a regression caused by commit 59fe4fe3, "thinkpad-acpi: fix incorrect use of TPACPI_BRGHT_MODE_ECNVRAM" Kernel 2.6.31 also needs this fix. Reported-by:
Ferenc Wagner <wferi@niif.hu> Tested-by:
-
Kirill A. Shutemov authored
commit cd9b45b7 upstream. A memory cgroup has a memory.memsw.usage_in_bytes file. It shows the sum of the usage of pages and swapents in the cgroup. Presently the root cgroup's memsw.usage_in_bytes shows the wrong value - the number of swapents are not added. So take MEM_CGROUP_STAT_SWAPOUT into account. Signed-off-by:
Kirill A. Shutemov <kirill@shutemov.name> Reviewed-by:
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> Acked-by:
-
Li Peng authored
commit 778c9026 upstream In current vblank-wait implementation, if we turn off VGA output, drm_wait_vblank will still wait on the disabled pipe until timeout, because vblank on the pipe is assumed be enabled. This would cause slow system response on some system such as moblin. This patch resolve the issue by adding a drm helper function drm_vblank_off which explicitly clear vblank_enabled[crtc], wake up any waiting queue and save last vblank counter before turning off crtc. It also slightly change drm_vblank_get to ensure that we will will return immediately if trying to wait on a disabled pipe. Signed-off-by:
Li Peng <peng.li@intel.com> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> [anholt: hand-applied for conflicts with overlay changes] Signed-off-by:
-
