- 13 Feb, 2012 40 commits
-
-
Marco Sanvido authored
commit 6816966a upstream. Initiators that aren't the active reservation holder should be able to do a PERSISTENT RESERVE IN command in all cases, so add it to the list of allowed CDBs in core_scsi3_pr_seq_non_holder(). Signed-off-by:
Marco Sanvido <marco@purestorage.com> Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Marco Sanvido authored
commit 9e08e34e upstream. The comments quote the right parts of the spec: * d) Establish a unit attention condition for the * initiator port associated with every I_T nexus * that lost its registration other than the I_T * nexus on which the PERSISTENT RESERVE OUT command * was received, with the additional sense code set * to REGISTRATIONS PREEMPTED. and * e) Establish a unit attention condition for the initiator * port associated with every I_T nexus that lost its * persistent reservation and/or registration, with the * additional sense code set to REGISTRATIONS PREEMPTED; but the actual code accidentally uses ASCQ_2AH_RESERVATIONS_PREEMPTED instead of ASCQ_2AH_REGISTRATIONS_PREEMPTED. Fix this. Signed-off-by:
-
Hugh Dickins authored
commit b9980cdc upstream. Fix CONFIG_TRANSPARENT_HUGEPAGE=y CONFIG_SMP=n CONFIG_DEBUG_VM=y CONFIG_DEBUG_SPINLOCK=n kernel: spin_is_locked() is then always false, and so triggers some BUGs in Transparent HugePage codepaths. asm-generic/bug.h mentions this problem, and provides a WARN_ON_SMP(x); but being too lazy to add VM_BUG_ON_SMP, BUG_ON_SMP, WARN_ON_SMP_ONCE, VM_WARN_ON_SMP_ONCE, just test NR_CPUS != 1 in the existing VM_BUG_ONs. Signed-off-by:
Hugh Dickins <hughd@google.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Mel Gorman authored
commit dc908600 upstream. When isolating pages for migration, migration starts at the start of a zone while the free scanner starts at the end of the zone. Migration avoids entering a new zone by never going beyond the free scanned. Unfortunately, in very rare cases nodes can overlap. When this happens, migration isolates pages without the LRU lock held, corrupting lists which will trigger errors in reclaim or during page free such as in the following oops BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: [<ffffffff810f795c>] free_pcppages_bulk+0xcc/0x450 PGD 1dda554067 PUD 1e1cb58067 PMD 0 Oops: 0000 [#1] SMP CPU 37 Pid: 17088, comm: memcg_process_s Tainted: G X RIP: free_pcppages_bulk+0xcc/0x450 Process memcg_process_s (pid: 17088, threadinfo ffff881c2926e000, task ffff881c2926c0c0) Call Trace: free_hot_cold_page+0x17e/0x1f0 __pagevec_free+0x90/0xb0 release_pages+0x22a/0x260 pagevec_lru_move_fn+0xf3/0x110 putback_lru_page+0x66/0xe0 unmap_and_move+0x156/0x180 migrate_pages+0x9e/0x1b0 compact_zone+0x1f3/0x2f0 compact_zone_order+0xa2/0xe0 try_to_compact_pages+0xdf/0x110 __alloc_pages_direct_compact+0xee/0x1c0 __alloc_pages_slowpath+0x370/0x830 __alloc_pages_nodemask+0x1b1/0x1c0 alloc_pages_vma+0x9b/0x160 do_huge_pmd_anonymous_page+0x160/0x270 do_page_fault+0x207/0x4c0 page_fault+0x25/0x30 The "X" in the taint flag means that external modules were loaded but but is unrelated to the bug triggering. The real problem was because the PFN layout looks like this Zone PFN ranges: DMA 0x00000010 -> 0x00001000 DMA32 0x00001000 -> 0x00100000 Normal 0x00100000 -> 0x01e80000 Movable zone start PFN for each node early_node_map[14] active PFN ranges 0: 0x00000010 -> 0x0000009b 0: 0x00000100 -> 0x0007a1ec 0: 0x0007a354 -> 0x0007a379 0: 0x0007f7ff -> 0x0007f800 0: 0x00100000 -> 0x00680000 1: 0x00680000 -> 0x00e80000 0: 0x00e80000 -> 0x01080000 1: 0x01080000 -> 0x01280000 0: 0x01280000 -> 0x01480000 1: 0x01480000 -> 0x01680000 0: 0x01680000 -> 0x01880000 1: 0x01880000 -> 0x01a80000 0: 0x01a80000 -> 0x01c80000 1: 0x01c80000 -> 0x01e80000 The fix is straight-forward. isolate_migratepages() has to make a similar check to isolate_freepage to ensure that it never isolates pages from a zone it does not hold the LRU lock for. This was discovered in a 3.0-based kernel but it affects 3.1.x, 3.2.x and current mainline. Signed-off-by:
Mel Gorman <mgorman@suse.de> Acked-by:
Michal Nazarewicz <mina86@mina86.com> Signed-off-by:
-
Joerg Roedel authored
commit 05df1f3c upstream. Error handling in msm_iommu_unmap() is broken. On some error conditions retval is set to a non-zero value which causes the function to return 'len' at the end. This hides the error from the user. Zero should be returned in those error cases. Cc: David Brown <davidb@codeaurora.org> Cc: Stepan Moskovchenko <stepanm@codeaurora.org> Signed-off-by:
Joerg Roedel <joerg.roedel@amd.com> Acked-by:
David Brown <davidb@codeaurora.org> Signed-off-by:
-
Joerg Roedel authored
commit af1be049 upstream. On some systems the IVRS table does not contain all PCI devices present in the system. In case a device not present in the IVRS table is translated by the IOMMU no DMA is possible from that device by default. This patch fixes this by removing the DTE entry for every PCI device present in the system and not covered by IVRS. Signed-off-by:
-
Clemens Ladisch authored
commit 2492250e upstream. The driver accidentally exchanged the left/right fields for stereo AC'97 mixer registers. This affected only the aux and CD inputs because the line input bypasses the AC'97 codec and the mic input is mono; cards without AC'97 (Xonar DS/DG/HDAV Slim, HG2PCI, HiFier) were not affected. Reported-and-tested-by:
Abby Cedar <abbycedar@yahoo.com.au> Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Russell King authored
commit 025e4ab3 upstream. This fixes a memory-corrupting bug: not only does it cause the warning, but as a result of dropping the refcount to zero, it causes the pcmcia_socket0 device structure to be freed while it still has references, causing slab caches corruption. A fatal oops quickly follows this warning - often even just a 'dmesg' following the warning causes the kernel to oops. While testing suspend/resume on an ARM device with PCMCIA support, and a CF card inserted, I found that after five suspend and resumes, the kernel would complain, and shortly die after with slab corruption. WARNING: at include/linux/kref.h:41 kobject_get+0x28/0x50() As the message doesn't give a clue about which kobject, and the built-in debugging in drivers/base/power/main.c happens too late, this was added right before each get_device(): printk("%s: %p [%s] %u\n", __func__, dev, kobject_name(&dev->kobj), atomic_read(&dev->kobj.kref.refcount)); and on the 3rd s2ram cycle, the following behaviour observed: On the 3rd suspend/resume cycle: dpm_prepare: c1a0d998 [pcmcia_socket0] 3 dpm_suspend: c1a0d998 [pcmcia_socket0] 3 dpm_suspend_noirq: c1a0d998 [pcmcia_socket0] 3 dpm_resume_noirq: c1a0d998 [pcmcia_socket0] 3 dpm_resume: c1a0d998 [pcmcia_socket0] 3 dpm_complete: c1a0d998 [pcmcia_socket0] 2 4th: dpm_prepare: c1a0d998 [pcmcia_socket0] 2 dpm_suspend: c1a0d998 [pcmcia_socket0] 2 dpm_suspend_noirq: c1a0d998 [pcmcia_socket0] 2 dpm_resume_noirq: c1a0d998 [pcmcia_socket0] 2 dpm_resume: c1a0d998 [pcmcia_socket0] 2 dpm_complete: c1a0d998 [pcmcia_socket0] 1 5th: dpm_prepare: c1a0d998 [pcmcia_socket0] 1 dpm_suspend: c1a0d998 [pcmcia_socket0] 1 dpm_suspend_noirq: c1a0d998 [pcmcia_socket0] 1 dpm_resume_noirq: c1a0d998 [pcmcia_socket0] 1 dpm_resume: c1a0d998 [pcmcia_socket0] 1 dpm_complete: c1a0d998 [pcmcia_socket0] 0 ------------[ cut here ]------------ WARNING: at include/linux/kref.h:41 kobject_get+0x28/0x50() Modules linked in: ucb1x00_core Backtrace: [<c0212090>] (dump_backtrace+0x0/0x110) from [<c04799dc>] (dump_stack+0x18/0x1c) [<c04799c4>] (dump_stack+0x0/0x1c) from [<c021cba0>] (warn_slowpath_common+0x50/0x68) [<c021cb50>] (warn_slowpath_common+0x0/0x68) from [<c021cbdc>] (warn_slowpath_null+0x24/0x28) [<c021cbb8>] (warn_slowpath_null+0x0/0x28) from [<c0335374>] (kobject_get+0x28/0x50) [<c033534c>] (kobject_get+0x0/0x50) from [<c03804f4>] (get_device+0x1c/0x24) [<c0388c90>] (dpm_complete+0x0/0x1a0) from [<c0389cc0>] (dpm_resume_end+0x1c/0x20) ... Looking at commit 7b24e798 ("pcmcia: split up central event handler"), the following change was made to cs.c: return 0; } #endif - - send_event(skt, CS_EVENT_PM_RESUME, CS_EVENT_PRI_LOW); + if (!(skt->state & SOCKET_CARDBUS) && (skt->callback)) + skt->callback->early_resume(skt); return 0; } And the corresponding change in ds.c is from: -static int ds_event(struct pcmcia_socket *skt, event_t event, int priority) -{ - struct pcmcia_socket *s = pcmcia_get_socket(skt); ... - switch (event) { ... - case CS_EVENT_PM_RESUME: - if (verify_cis_cache(skt) != 0) { - dev_dbg(&skt->dev, "cis mismatch - different card\n"); - /* first, remove the card */ - ds_event(skt, CS_EVENT_CARD_REMOVAL, CS_EVENT_PRI_HIGH); - mutex_lock(&s->ops_mutex); - destroy_cis_cache(skt); - kfree(skt->fake_cis); - skt->fake_cis = NULL; - s->functions = 0; - mutex_unlock(&s->ops_mutex); - /* now, add the new card */ - ds_event(skt, CS_EVENT_CARD_INSERTION, - CS_EVENT_PRI_LOW); - } - break; ... - } - pcmcia_put_socket(s); - return 0; -} /* ds_event */ to: +static int pcmcia_bus_early_resume(struct pcmcia_socket *skt) +{ + if (!verify_cis_cache(skt)) { + pcmcia_put_socket(skt); + return 0; + } + dev_dbg(&skt->dev, "cis mismatch - different card\n"); + /* first, remove the card */ + pcmcia_bus_remove(skt); + mutex_lock(&skt->ops_mutex); + destroy_cis_cache(skt); + kfree(skt->fake_cis); + skt->fake_cis = NULL; + skt->functions = 0; + mutex_unlock(&skt->ops_mutex); + /* now, add the new card */ + pcmcia_bus_add(skt); + return 0; +} As can be seen, the original function called pcmcia_get_socket() and pcmcia_put_socket() around the guts, whereas the replacement code calls pcmcia_put_socket() only in one path. This creates an imbalance in the refcounting. Testing with pcmcia_put_socket() put removed shows that the bug is gone: dpm_suspend: c1a10998 [pcmcia_socket0] 5 dpm_suspend_noirq: c1a10998 [pcmcia_socket0] 5 dpm_resume_noirq: c1a10998 [pcmcia_socket0] 5 dpm_resume: c1a10998 [pcmcia_socket0] 5 dpm_complete: c1a10998 [pcmcia_socket0] 5 Tested-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Mark Brown authored
commit f647e152 upstream. The VMID ramp rate is supposed to be 0x3, not 11b. Fix that. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Mark Brown authored
commit db966f8a upstream. We can enable VMID independently of the bias in some use cases so we need to ensure that the core device is powered up. Signed-off-by:
-
Susan Gao authored
commit 2b6712b1 upstream. Signed-off-by:
Susan Gao <sgao@opensource.wolfsonmicro.com> Signed-off-by:
-
Mark Brown authored
commit 43b6cec2 upstream. The second line output mixer has the controls for the line input bypasses in the opposite order. Signed-off-by:
-
Mark Brown authored
commit ee76744c upstream. IN1L/R is routed to both line output mixers, we don't route IN1 to LINEOUT1 and IN2 to LINEOUT2. Signed-off-by:
-
Nicholas Bellinger authored
commit 2f9bc894 upstream. This patch addresses a bug with sendtargets discovery where INADDR_ANY (0.0.0.0) + IN6ADDR_ANY_INIT ([0:0:0:0:0:0:0:0]) network portals where incorrectly being reported back to initiators instead of the address of the connecting interface. To address this, save local socket ->getname() output during iscsi login setup, and makes iscsit_build_sendtargets_response() return these TargetAddress keys when INADDR_ANY or IN6ADDR_ANY_INIT portals are in use. Reported-by:
Dax Kelson <dkelson@gurulabs.com> Reported-by:
Andy Grover <agrover@redhat.com> Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
-
Nicholas Bellinger authored
commit cd931ee6 upstream. This patch fixes a bug where the iscsit_add_reject_from_cmd() call from a failure to iscsit_alloc_buffs() was incorrectly passing add_to_conn=1 and causing a double list_add after iscsi_cmd->i_list had already been added in iscsit_handle_scsi_cmd(). Signed-off-by:
-
Nicholas Bellinger authored
commit c1ce4bd5 upstream. This patch addresses a bug where iscsit_free_cmd() was incorrectly calling iscsit_release_cmd() for ISCSI_OP_REJECT because iscsi_add_reject*() will overwrite the original iscsi_cmd->iscsi_opcode assignment. This bug was introduced with the following commit: commit 0be67f2ed8f577d2c72d917928394c5885fa9134 Author: Nicholas Bellinger <nab@linux-iscsi.org> Date: Sun Oct 9 01:48:14 2011 -0700 iscsi-target: Remove SCF_SE_LUN_CMD flag abuses and was manifesting itself as list corruption with the following: [ 131.191092] ------------[ cut here ]------------ [ 131.191092] WARNING: at lib/list_debug.c:53 __list_del_entry+0x8d/0x98() [ 131.191092] Hardware name: VMware Virtual Platform [ 131.191092] list_del corruption. prev->next should be ffff880022d3c100, but was 6b6b6b6b6b6b6b6b [ 131.191092] Modules linked in: tcm_vhost ib_srpt ib_cm ib_sa ib_mad ib_core tcm_qla2xxx qla2xxx tcm_loop tcm_fc libfc scsi_transport_fc crc32c iscsi_target_mod target_core_stgt scsi_tgt target_core_pscsi target_core_file target_core_iblock target_core_mod configfs ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi sr_mod cdrom sd_mod e1000 ata_piix libata mptspi mptscsih mptbase [last unloaded: scsi_wait_scan] [ 131.191092] Pid: 2250, comm: iscsi_ttx Tainted: G W 3.2.0-rc4+ #42 [ 131.191092] Call Trace: [ 131.191092] [<ffffffff8103b553>] warn_slowpath_common+0x80/0x98 [ 131.191092] [<ffffffff8103b5ff>] warn_slowpath_fmt+0x41/0x43 [ 131.191092] [<ffffffff811d0279>] __list_del_entry+0x8d/0x98 [ 131.191092] [<ffffffffa01395c9>] transport_lun_remove_cmd+0x9b/0xb7 [target_core_mod] [ 131.191092] [<ffffffffa013a55c>] transport_generic_free_cmd+0x5d/0x71 [target_core_mod] [ 131.191092] [<ffffffffa01a012b>] iscsit_free_cmd+0x1e/0x27 [iscsi_target_mod] [ 131.191092] [<ffffffffa01a13be>] iscsit_close_connection+0x14d/0x5b2 [iscsi_target_mod] [ 131.191092] [<ffffffffa0196a0c>] iscsit_take_action_for_connection_exit+0xdb/0xe0 [iscsi_target_mod] [ 131.191092] [<ffffffffa01a55d4>] iscsi_target_tx_thread+0x15cb/0x1608 [iscsi_target_mod] [ 131.191092] [<ffffffff8103609a>] ? check_preempt_wakeup+0x121/0x185 [ 131.191092] [<ffffffff81030801>] ? __dequeue_entity+0x2e/0x33 [ 131.191092] [<ffffffffa01a4009>] ? iscsit_send_text_rsp+0x25f/0x25f [iscsi_target_mod] [ 131.191092] [<ffffffffa01a4009>] ? iscsit_send_text_rsp+0x25f/0x25f [iscsi_target_mod] [ 131.191092] [<ffffffff8138f706>] ? schedule+0x55/0x57 [ 131.191092] [<ffffffff81056c7d>] kthread+0x7d/0x85 [ 131.191092] [<ffffffff81399534>] kernel_thread_helper+0x4/0x10 [ 131.191092] [<ffffffff81056c00>] ? kthread_worker_fn+0x16d/0x16d [ 131.191092] [<ffffffff81399530>] ? gs_change+0x13/0x13 Reported-by: <jrepac@yahoo.com> Signed-off-by:
-
Ben Hutchings authored
commit 9ec84ace upstream. We do want to allow lock debugging for GPL-compatible modules that are not (yet) built in-tree. This was disabled as a side-effect of commit 2449b8ba ('module,bug: Add TAINT_OOT_MODULE flag for modules not built in-tree'). Lock debug warnings now include taint flags, so kernel developers should still be able to deflect warnings caused by out-of-tree modules. The TAINT_PROPRIETARY_MODULE flag for non-GPL-compatible modules will still disable lock debugging. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Cc: Nick Bowler <nbowler@elliptictech.com> Cc: Dave Jones <davej@redhat.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Randy Dunlap <rdunlap@xenotime.net> Cc: Debian kernel maintainers <debian-kernel@lists.debian.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Alan Cox <alan@linux.intel.com> Link: http://lkml.kernel.org/r/1323268258.18450.11.camel@deadeyeSigned-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Peter Zijlstra authored
commit df754e6a upstream. It's unlikely that TAINT_FIRMWARE_WORKAROUND causes false lockdep messages, so do not disable lockdep in that case. We still want to keep lockdep disabled in the TAINT_OOT_MODULE case: - bin-only modules can cause various instabilities in their and in unrelated kernel code - they are impossible to debug for kernel developers - they also typically do not have the copyright license permission to link to the GPL-ed lockdep code. Suggested-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/n/tip-xopopjjens57r0i13qnyh2yo@git.kernel.orgSigned-off-by:
-
Hubert Feurstein authored
commit 9f106503 upstream. An error was existing in the saving of CONTRAST_CTR register across suspend/resume. Signed-off-by:
Hubert Feurstein <h.feurstein@gmail.com> Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by:
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by:
Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Signed-off-by:
-
Shirish Pargaonkar authored
commit de47a417 upstream. For null user mounts, do not invoke string length function during session setup. Reported-and-Tested-by:
Chris Clayton <chris2553@googlemail.com> Acked-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Shirish Pargaonkar <shirishpargaonkar@gmail.com> Signed-off-by:
Steve French <smfrench@gmail.com> Signed-off-by:
-
Guenter Roeck authored
commit 585c0fd8 upstream. NCT6776F can select fan input pins for fans 3 to 5 with a secondary set of chip register bits. Check that second set of bits in addition to the first set to detect if fans 3..5 are monitored. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Acked-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Li Wang authored
commit 684a3ff7 upstream. ecryptfs_write() can enter an infinite loop when truncating a file to a size larger than 4G. This only happens on architectures where size_t is represented by 32 bits. This was caused by a size_t overflow due to it incorrectly being used to store the result of a calculation which uses potentially large values of type loff_t. [tyhicks@canonical.com: rewrite subject and commit message] Signed-off-by:
Li Wang <liwang@nudt.edu.cn> Signed-off-by:
Yunchuan Wen <wenyunchuan@kylinos.com.cn> Reviewed-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Signed-off-by:
-
Daniel Vetter authored
commit 9f1f46a4 upstream. The problem this patch solves is that the forcewake accounting necessary for register reads is protected by dev->struct_mutex. But the hangcheck and error_capture code need to access registers without grabbing this mutex because we hold it while waiting for the gpu. So a new lock is required. Because currently the error_state capture is called from the error irq handler and the hangcheck code runs from a timer, it needs to be an irqsafe spinlock (note that the registers used by the irq handler (neglecting the error handling part) only uses registers that don't need the forcewake dance). We could tune this down to a normal spinlock when we rework the error_state capture and hangcheck code to run from a workqueue. But we don't have any read in a fastpath that needs forcewake, so I've decided to not care much about overhead. This prevents tests/gem_hangcheck_forcewake from i-g-t from killing my snb on recent kernels - something must have slightly changed the timings. On previous kernels it only trigger a WARN about the broken locking. v2: Drop the previous patch for the register writes. v3: Improve the commit message per Chris Wilson's suggestions. Signed-Off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
-
Daniel Vetter authored
commit 81090213 upstream. This was forgotten in the original multi-threaded forcewake conversion: commit 8d715f00 Author: Keith Packard <keithp at keithp.com> Date: Fri Nov 18 20:39:01 2011 -0800 drm/i915: add multi-threaded forcewake support Signed-off-by:
-
Eugeni Dodonov authored
commit 07c1e8c1 upstream. We don't need to check 3rd pipe specifically, as it shares PLL with some other one. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41977Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Rodrigo Vivi authored
commit 23bd15ec upstream. TV Out refresh rate was half of the specification for almost all modes. Due to this reason pixel clock was so low for some modes causing flickering screen. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by:
-
Daniel Vetter authored
commit 097354eb upstream. Otherwise hangcheck spuriously fires when running blitter/bsd-only workloads. Contrary to a similar patch by Ben Widawsky this does not check INSTDONE of the other rings. Chris Wilson implied that in a failure to detect a hang, most likely because INSTDONE was fluctuating. Thus only check ACTHD, which as far as I know is rather reliable. Also, blitter and bsd rings can't launch complex tasks from a single instruction (like 3D_PRIM on the render with complex or even infinite shaders). This fixes spurious gpu hang detection when running tests/gem_hangcheck_forcewake on snb/ivb. Signed-Off-by:
-
Wu Fengguang authored
commit 832afda6 upstream. On DP monitor hot remove, clear DP_AUDIO_OUTPUT_ENABLE accordingly, so that the audio driver will receive hot plug events and take action to refresh its device state and ELD contents. Note that the DP_AUDIO_OUTPUT_ENABLE bit may be enabled or disabled only when the link training is complete and set to "Normal". Tested OK for both hot plug/remove and DPMS on/off. Signed-off-by:
Wu Fengguang <fengguang.wu@intel.com> Signed-off-by:
-
Wu Fengguang authored
commit 2deed761 upstream. On HDMI monitor hot remove, clear SDVO_AUDIO_ENABLE accordingly, so that the audio driver will receive hot plug events and take action to refresh its device state and ELD contents. The cleared SDVO_AUDIO_ENABLE bit needs to be restored to prevent losing HDMI audio after DPMS on. CC: Wang Zhenyu <zhenyu.z.wang@intel.com> Signed-off-by:
-
Jan Kara authored
commit 853a0c25 upstream. When we hit EIO while writing LVID, the buffer uptodate bit is cleared. This then results in an anoying warning from mark_buffer_dirty() when we write the buffer again. So just set uptodate flag unconditionally. Reviewed-by:
Namjae Jeon <linkinjeon@gmail.com> Signed-off-by:
Jan Kara <jack@suse.cz> Cc: Dave Jones <davej@redhat.com> Signed-off-by:
-
Francois Romieu authored
commit b189e810 upstream. The driver uses __napi_complete and napi_gro_receive. Without it, the driver hits the BUG_ON(n->gro_list) assertion hard in __napi_complete. Signed-off-by:
Francois Romieu <romieu@fr.zoreil.com> Tested-by:
Marin Glibic <zhilla2@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Srivatsa S. Bhat authored
commit fe9161db upstream. In the SNAPSHOT_CREATE_IMAGE ioctl, if the call to hibernation_snapshot() fails, the frozen tasks are not thawed. And in the case of success, if we happen to exit due to a successful freezer test, all tasks (including those of userspace) are thawed, whereas actually we should have thawed only the kernel threads at that point. Fix both these issues. Signed-off-by:
Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
-
Srivatsa S. Bhat authored
commit 97819a26 upstream. Commit 2aede851 (PM / Hibernate: Freeze kernel threads after preallocating memory) moved the freezing of kernel threads to hibernation_snapshot() function. So now, if the call to hibernation_snapshot() returns early due to a successful hibernation test, the caller has to thaw processes to ensure that the system gets back to its original state. But in SNAPSHOT_CREATE_IMAGE hibernation ioctl, the caller does not thaw processes in case hibernation_snapshot() returned due to a successful freezer test. Fix this issue. But note we still send the value of 'in_suspend' (which is now 0) to userspace, because we are not in an error path per-se, and moreover, the value of in_suspend correctly depicts the situation here. Signed-off-by:
-
Chanho Min authored
commit cb297a3e upstream. This issue happens under the following conditions: 1. preemption is off 2. __ARCH_WANT_INTERRUPTS_ON_CTXSW is defined 3. RT scheduling class 4. SMP system Sequence is as follows: 1.suppose current task is A. start schedule() 2.task A is enqueued pushable task at the entry of schedule() __schedule prev = rq->curr; ... put_prev_task put_prev_task_rt enqueue_pushable_task 4.pick the task B as next task. next = pick_next_task(rq); 3.rq->curr set to task B and context_switch is started. rq->curr = next; 4.At the entry of context_swtich, release this cpu's rq->lock. context_switch prepare_task_switch prepare_lock_switch raw_spin_unlock_irq(&rq->lock); 5.Shortly after rq->lock is released, interrupt is occurred and start IRQ context 6.try_to_wake_up() which called by ISR acquires rq->lock try_to_wake_up ttwu_remote rq = __task_rq_lock(p) ttwu_do_wakeup(rq, p, wake_flags); task_woken_rt 7.push_rt_task picks the task A which is enqueued before. task_woken_rt push_rt_tasks(rq) next_task = pick_next_pushable_task(rq) 8.At find_lock_lowest_rq(), If double_lock_balance() returns 0, lowest_rq can be the remote rq. (But,If preemption is on, double_lock_balance always return 1 and it does't happen.) push_rt_task find_lock_lowest_rq if (double_lock_balance(rq, lowest_rq)).. 9.find_lock_lowest_rq return the available rq. task A is migrated to the remote cpu/rq. push_rt_task ... deactivate_task(rq, next_task, 0); set_task_cpu(next_task, lowest_rq->cpu); activate_task(lowest_rq, next_task, 0); 10. But, task A is on irq context at this cpu. So, task A is scheduled by two cpus at the same time until restore from IRQ. Task A's stack is corrupted. To fix it, don't migrate an RT task if it's still running. Signed-off-by:
Chanho Min <chanho.min@lge.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Link: http://lkml.kernel.org/r/CAOAMb1BHA=5fm7KTewYyke6u-8DP0iUuJMpgQw54vNeXFsGpoQ@mail.gmail.comSigned-off-by:
-
Alex Deucher authored
commit 304a4840 upstream. Different versions of the DP to LVDS bridge chip need different panel mode settings depending on the chip version used. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=41569Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Seth Forshee authored
commit 86698c20 upstream. Polling the outputs when the device is suspended can result in erroneous status updates. Disable output polling during suspend to prevent this from happening. Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Reviewed-by:
-
Ben Skeggs authored
commit 525895ba upstream. Due to a race it was possible for a fence to be destroyed while another thread was trying to synchronise with it. If this happened in the fallback non-semaphore path, it lead to the following oops due to fence->channel being NULL. BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<fa9632ce>] nouveau_fence_update+0xe/0xe0 [nouveau] *pde = a649c067 SMP Modules linked in: fuse nouveau(O) ttm(O) drm_kms_helper(O) drm(O) mxm_wmi video wmi netconsole configfs lockd bnep bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ip6table_filter ip6_tables snd_hda_codec_realtek snd_hda_intel snd_hda_cobinfmt_misc uinput ata_generic pata_acpi pata_aet2c_algo_bit i2c_core [last unloaded: wmi] Pid: 2255, comm: gnome-shell Tainted: G O 3.2.0-0.rc5.git0.1.fc17.i686 #1 System manufacturer System Product Name/M2A-VM EIP: 0060:[<fa9632ce>] EFLAGS: 00010296 CPU: 1 EIP is at nouveau_fence_update+0xe/0xe0 [nouveau] EAX: 00000000 EBX: ddfc6dd0 ECX: dd111580 EDX: 00000000 ESI: 00003e80 EDI: dd111580 EBP: dd121d00 ESP: dd121ce8 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process gnome-shell (pid: 2255, ti=dd120000 task=dd111580 task.ti=dd120000) Stack: 7dc86c76 00000000 00003e80 ddfc6dd0 00003e80 dd111580 dd121d0c fa96371f 00000000 dd121d3c fa963773 dd111580 01000246 000ec53d 00000000 ddfc6dd0 00001f40 00000000 ddfc6dd0 00000010 dc7df840 dd121d6c fa9639a0 00000000 Call Trace: [<fa96371f>] __nouveau_fence_signalled+0x1f/0x30 [nouveau] [<fa963773>] __nouveau_fence_wait+0x43/0xd0 [nouveau] [<fa9639a0>] nouveau_fence_sync+0x1a0/0x1c0 [nouveau] [<fa964046>] validate_list+0x176/0x300 [nouveau] [<f7d9c9c0>] ? ttm_bo_mem_put+0x30/0x30 [ttm] [<fa964b8a>] nouveau_gem_ioctl_pushbuf+0x48a/0xfd0 [nouveau] [<c0406481>] ? die+0x31/0x80 [<f7c93d98>] drm_ioctl+0x388/0x490 [drm] [<c0406481>] ? die+0x31/0x80 [<fa964700>] ? nouveau_gem_ioctl_new+0x150/0x150 [nouveau] [<c0635c7b>] ? file_has_perm+0xcb/0xe0 [<f7c93a10>] ? drm_copy_field+0x80/0x80 [drm] [<c0564f56>] do_vfs_ioctl+0x86/0x5b0 [<c0406481>] ? die+0x31/0x80 [<c0635f22>] ? selinux_file_ioctl+0x62/0x130 [<c0554f30>] ? fget_light+0x30/0x340 [<c05654ef>] sys_ioctl+0x6f/0x80 [<c099e3a4>] syscall_call+0x7/0xb [<c0406481>] ? die+0x31/0x80 [<c0406481>] ? die+0x31/0x80 Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Michel Dänzer authored
commit 1b619250 upstream. The value of this register is transferred to the V_COUNTER register at the beginning of vertical blank. V_COUNTER is the reference for VLINE waits and goes from VIEWPORT_Y_START to VIEWPORT_Y_START+VIEWPORT_HEIGHT during scanout, so if VIEWPORT_Y_START is not 0, V_COUNTER actually went backwards at the beginning of vertical blank, and VLINE waits excluding the whole scanout area could never finish (possibly only if VIEWPORT_Y_START is larger than the length of vertical blank in scanlines). Setting DESKTOP_HEIGHT to the framebuffer height should prevent this for any kind of VLINE wait. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=45329 . Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Reviewed-by:
-
Venkatesh Pallipadi authored
commit d020283d upstream. Looks like change "PM QoS: Move and rename the implementation files" merged during the 3.2 development cycle made PM QoS depend on CONFIG_PM which depends on (PM_SLEEP || PM_RUNTIME). That breaks CPU C-states with kernels not having these CONFIGs, causing CPUs to spend time in Polling loop idle instead of going into deep C-states, consuming way way more power. This is with either acpi idle or intel idle enabled. Either CONFIG_PM should be enabled with any pm_qos users or the !CONFIG_PM pm_qos_request() should return sane defaults not to break the existing users. Here's is the patch for the latter option. [rjw: Modified the changelog slightly.] Signed-off-by:
Venkatesh Pallipadi <venki@google.com> Signed-off-by:
-
Rafael J. Wysocki authored
commit 181e9bde upstream. Commit 2aede851 PM / Hibernate: Freeze kernel threads after preallocating memory introduced a mechanism by which kernel threads were frozen after the preallocation of hibernate image memory to avoid problems with frozen kernel threads not responding to memory freeing requests. However, it overlooked the s2disk code path in which the SNAPSHOT_CREATE_IMAGE ioctl was run directly after SNAPSHOT_FREE, which caused freeze_workqueues_begin() to BUG(), because it saw that worqueues had been already frozen. Although in principle this issue might be addressed by removing the relevant BUG_ON() from freeze_workqueues_begin(), that would reintroduce the very problem that commit 2aede851 attempted to avoid into that particular code path. For this reason, to fix the issue at hand, introduce thaw_kernel_threads() and make the SNAPSHOT_FREE ioctl execute it. Special thanks to Srivatsa S. Bhat for detailed analysis of the problem. Reported-and-tested-by:
Jiri Slaby <jslaby@suse.cz> Signed-off-by:
-
