- 22 Apr, 2012 6 commits
-
-
Jesse Barnes authored
commit f57f9c16 upstream. People have been getting confused and thinking this is a runtime control. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Daniel Vetter authored
commit c4867936 upstream. We've only computed whether we need to fall back to 6bpc due to dp link bandwidth constrains in mode_valid, but not mode_fixup. Under various circumstances X likes to create new modes which then lack proper 6bpc flags (if required), resulting in mode_fixup failures and ultimately black screens. Chris Wilson pointed out that we still get things wrong for bpp > 24, but that should be fixed in another patch (and it'll be easier because this patch consolidates the logic). The likely culprit for this regression is commit 3d794f87 Author: Keith Packard <keithp@keithp.com> Date: Wed Jan 25 08:16:25 2012 -0800 drm/i915: Force explicit bpp selection for intel_dp_link_required v2: Fix indentation and tune down the too bold claim that this should fix the world. Both noticed by Chris Wilson. v3: Try to really git add things. Reported-and-tested-by:
Brice Goglin <Brice.Goglin@ens-lyon.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48170 Cc: stable@kernel.org Reviewed-by:
Adam Jackson <ajax@redhat.com> Signed-Off-by:
-
Alex Deucher authored
commit 46783150 upstream. It seems it can corrupt the monitor EDID in certain cases on certain boards when running sensors detect. It's rarely used anyway outside of AIW boards. http://lists.lm-sensors.org/pipermail/lm-sensors/2012-April/035847.html http://lists.freedesktop.org/archives/xorg/2011-January/052239.htmlSigned-off-by:
Alex Deucher <alexander.deucher@amd.com> Acked-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Chris Wilson authored
commit 27c1cbd0 upstream. The 845g shares the errata with i830 whereby executing a command within 2 cachelines of the end of the ringbuffer may cause a GPU hang. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Alex Deucher authored
commit afceb931 upstream. Some r4xx chips have the wrong frev in the DVOEncoderControl table. It should always be 1 on r4xx. Fixes modesetting on DVO on r4xx chips with the bad frev. Reported by twied on #radeon. Signed-off-by:
-
Jesse Barnes authored
commit 7885d205 upstream. The transcoder port may changed from mode set to mode set, so make sure to mask out the selection bits before setting the right ones or we'll get black screens when going from transcoder B to A. Tested-by:
Vincent Vanackere <vincent.vanackere@gmail.com> Signed-off-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
-
- 13 Apr, 2012 34 commits
-
-
Greg Kroah-Hartman authored
-
Peter Hurley authored
commit 18daf164 upstream Commit 33060542 fixed l2cap conn establishment for non-ssp remote devices by not setting HCI_CONN_ENCRYPT_PEND every time conn security is tested (which was always returning failure on any subsequent security checks). However, this broke l2cap conn establishment for ssp remote devices when an ACL link was already established at SDP-level security. This fix ensures that encryption must be pending whenever authentication is also pending. Signed-off-by:
Peter Hurley <peter@hurleysoftware.com> Tested-by:
Daniel Wagner <daniel.wagner@bmw-carit.de> Acked-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com>
-
Joerg Roedel authored
commit 9ddd592a upstream Unfortunatly the interrupts for the event log and the peripheral page-faults are only enabled at boot but not re-enabled at resume. Fix that for 3.2. Cc: stable@vger.kernel.org Signed-off-by:
Joerg Roedel <joerg.roedel@amd.com>
-
Oleg Nesterov authored
commit 79549c6d upstream. keyctl_session_to_parent(task) sets ->replacement_session_keyring, it should be processed and cleared by key_replace_session_keyring(). However, this task can fork before it notices TIF_NOTIFY_RESUME and the new child gets the bogus ->replacement_session_keyring copied by dup_task_struct(). This is obviously wrong and, if nothing else, this leads to put_cred(already_freed_cred). change copy_creds() to clear this member. If copy_process() fails before this point the wrong ->replacement_session_keyring doesn't matter, exit_creds() won't be called. Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Acked-by:
David Howells <dhowells@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Kuninori Morimoto authored
commit 1f99e44c upstream. ak4642 out_tlv is +12.0dB to -115.0 dB, and it supports mute. But current settings didn't care +1 step for mute. This patch adds it Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Dan Williams authored
commit 27502935 upstream. Starting with v3.2 Jonathan reports that Xen crashes loading the ioatdma driver. A debug run shows: ioatdma 0000:00:16.4: desc[0]: (0x300cc7000->0x300cc7040) cookie: 0 flags: 0x2 ctl: 0x29 (op: 0 int_en: 1 compl: 1) ... ioatdma 0000:00:16.4: ioat_get_current_completion: phys_complete: 0xcc7000 ...which shows that in this environment GFP_KERNEL memory may be backed by a 64-bit dma address. This breaks the driver's assumption that an unsigned long should be able to contain the physical address for descriptor memory. Switch to dma_addr_t which beyond being the right size, is the true type for the data i.e. an io-virtual address inidicating the engine's last processed descriptor. Reported-by:
Jonathan Nieder <jrnieder@gmail.com> Reported-by:
William Dauchy <wdauchy@gmail.com> Tested-by:
Dave Jiang <dave.jiang@intel.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Guan Xin authored
commit a2daf263 upstream. Added Vendor/Device Id of Motorola Rokr E6 (22b8:6027) so it can be recognized by the "zaurus" USBNet driver. Applies to Linux 3.2.13 and 2.6.39.4. Signed-off-by:
Guan Xin <guanx.bac@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Nishanth Menon authored
commit 3f8349e6 upstream. TWL6030 family of PMIC use a shadow interrupt status register while kernel processes the current interrupt event. However, any write(0 or 1) to register INT_STS_A, INT_STS_B or INT_STS_C clears all 3 interrupt status registers. Since clear of the interrupt is done on 32k clk, depending on I2C bus speed, we could in-adverently clear the status of a interrupt status pending on shadow register in the current implementation. This is due to the fact that multi-byte i2c write operation into three seperate status register could result in multiple load and clear of status and result in lost interrupts. Instead, doing a single byte write to INT_STS_A register with 0x0 will clear all three interrupt status registers without the related risk. Acked-by:
Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
-
Salman Qazi authored
commit 9993bc63 upstream. When a machine boots up, the TSC generally gets reset. However, when kexec is used to boot into a kernel, the TSC value would be carried over from the previous kernel. The computation of cycns_offset in set_cyc2ns_scale is prone to an overflow, if the machine has been up more than 208 days prior to the kexec. The overflow happens when we multiply *scale, even though there is enough room to store the final answer. We fix this issue by decomposing tsc_now into the quotient and remainder of division by CYC2NS_SCALE_FACTOR and then performing the multiplication separately on the two components. Refactor code to share the calculation with the previous fix in __cycles_2_ns(). Signed-off-by:
Salman Qazi <sqazi@google.com> Acked-by:
John Stultz <john.stultz@linaro.org> Acked-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Turner <pjt@google.com> Cc: john stultz <johnstul@us.ibm.com> Link: http://lkml.kernel.org/r/20120310004027.19291.88460.stgit@dungbeetle.mtv.corp.google.comSigned-off-by:
Ingo Molnar <mingo@elte.hu> Cc: Mike Galbraith <efault@gmx.de> Signed-off-by:
-
Sachin Prabhu authored
commit 20e0fa98 upstream. _copy_from_pages() used to copy data from the temporary buffer to the user passed buffer is passed the wrong size parameter when copying data. res.acl_len contains both the bitmap and acl lenghts while acl_len contains the acl length after adjusting for the bitmap size. Signed-off-by:
Sachin Prabhu <sprabhu@redhat.com> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Cc: Josh Boyer <jwboyer@redhat.com> Signed-off-by:
-
Lee, Chun-Yi authored
commit 5719b819 upstream. The wireless rfkill should charged by sony-laptop but not acer-wmi. So, add Sony's SNY5001 acpi device to blacklist in acer-wmi. Tested on Sony Vaio Cc: Carlos Corbacho <carlos@strangeworlds.co.uk> Cc: Matthew Garrett <mjg@redhat.com> Cc: Mattia Dongili <malattia@linux.it> Cc: Dimitris N <ddarlac@gmail.com> Tested-by:
Dimitris N <ddarlac@gmail.com> Signed-off-by:
Lee, Chun-Yi <jlee@suse.com> Signed-off-by:
Matthew Garrett <mjg@redhat.com> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 273fb194 [73d63d03 upstream] It causes problems, so needs to be reverted from 3.2-stable for now. Reported-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Jon Dufresne <jon@jondufresne.org> Cc: Suresh Siddha <suresh.b.siddha@intel.com> Cc: <yinghai@kernel.org> Cc: Josh Boyer <jwboyer@redhat.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Teck Choon Giam <giamteckchoon@gmail.com> Cc: Ben Guthro <ben@guthro.net> Signed-off-by:
-
Tetsuo Handa authored
commit df91e494 upstream. Userspace can pass in arbitrary combinations of MS_* flags to mount(). If both MS_BIND and one of MS_SHARED/MS_PRIVATE/MS_SLAVE/MS_UNBINDABLE are passed, device name which should be checked for MS_BIND was not checked because MS_SHARED/MS_PRIVATE/MS_SLAVE/MS_UNBINDABLE had higher priority than MS_BIND. If both one of MS_BIND/MS_MOVE and MS_REMOUNT are passed, device name which should not be checked for MS_REMOUNT was checked because MS_BIND/MS_MOVE had higher priority than MS_REMOUNT. Fix these bugs by changing priority to MS_REMOUNT -> MS_BIND -> MS_SHARED/MS_PRIVATE/MS_SLAVE/MS_UNBINDABLE -> MS_MOVE as with do_mount() does. Also, unconditionally return -EINVAL if more than one of MS_SHARED/MS_PRIVATE/MS_SLAVE/MS_UNBINDABLE is passed so that TOMOYO will not generate inaccurate audit logs, for commit 7a2e8a8f "VFS: Sanity check mount flags passed to change_mnt_propagation()" clarified that these flags must be exclusively passed. Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by:
James Morris <james.l.morris@oracle.com> Signed-off-by:
-
Jonathan Nieder authored
commit a97f4f5e upstream. Carlos was getting WARNING: at drivers/pci/pci.c:118 pci_ioremap_bar+0x24/0x52() when probing his sound card, and sound did not work. After adding pci=use_crs to the kernel command line, no more trouble. Ok, we can add a quirk. dmidecode output reveals that this is an MSI MS-7253, for which we already have a quirk, but the short-sighted author tied the quirk to a single BIOS version, making it not kick in on Carlos's machine with BIOS V1.2. If a later BIOS update makes it no longer necessary to look at the _CRS info it will still be harmless, so let's stop trying to guess which versions have and don't have accurate _CRS tables. Addresses https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5533 Also see <https://bugzilla.kernel.org/show_bug.cgi?id=42619>. Reported-by:
Carlos Luna <caralu74@gmail.com> Reviewed-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Jonathan Nieder authored
commit 84113717 upstream. In the spirit of commit 29cf7a30 ("x86/PCI: use host bridge _CRS info on ASUS M2V-MX SE"), this DMI quirk turns on "pci_use_crs" by default on a board that needs it. This fixes boot failures and oopses introduced in 3e3da00c ("x86/pci: AMD one chain system to use pci read out res"). The quirk is quite targetted (to a specific board and BIOS version) for two reasons: (1) to emphasize that this method of tackling the problem one quirk at a time is a little insane (2) to give BIOS vendors an opportunity to use simpler tables and allow us to return to generic behavior (whatever that happens to be) with a later BIOS update In other words, I am not at all happy with having quirks like this. But it is even worse for the kernel not to work out of the box on these machines, so... Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42619Reported-by:
Svante Signell <svante.signell@telia.com> Signed-off-by:
-
Frank Rowand authored
commit 258f7426 upstream. Commit f02e8a65 ("module: Sort exported symbols") sorts symbols placing each of them in its own elf section. This sorting and merging into the canonical sections are done by the linker. Unfortunately modpost to generate Module.symvers file parses vmlinux.o (which is not linked yet) and all modules object files (which aren't linked yet). These aren't sanitized by the linker yet. That breaks modpost that can't detect license properly for modules. This patch makes modpost aware of the new exported symbols structure. [ This above is a slightly corrected version of the explanation of the problem, copied from commit 62a26356 ("modpost: Fix modpost's license checking V3"). That commit fixed the problem for module object files, but not for vmlinux.o. This patch fixes modpost for vmlinux.o. ] Signed-off-by:
Frank Rowand <frank.rowand@am.sony.com> Signed-off-by:
Alessio Igor Bogani <abogani@kernel.org> Signed-off-by:
-
Kees Cook authored
commit 620f6e8e upstream. Commit bfdc0b49 adds code to restrict access to dmesg_restrict, however, it incorrectly alters kptr_restrict rather than dmesg_restrict. The original patch from Richard Weinberger (https://lkml.org/lkml/2011/3/14/362) alters dmesg_restrict as expected, and so the patch seems to have been misapplied. This adds the CAP_SYS_ADMIN check to both dmesg_restrict and kptr_restrict, since both are sensitive. Reported-by:
Phillip Lougher <plougher@redhat.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Acked-by:
Serge Hallyn <serge.hallyn@canonical.com> Acked-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Mark Rustad authored
commit 06383f10 upstream. Avoid freeing a registered tpg structure if an alloc_workqueue call fails. This fixes a bug where the failure was leaking memory associated with se_portal_group setup during the original core_tpg_register() call. Signed-off-by:
Mark Rustad <mark.d.rustad@intel.com> Acked-by:
Kiran Patil <Kiran.patil@intel.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Mark Rustad authored
commit e1c40382 upstream. Add abort flag and use it to terminate processing when an exchange is timed out or is reset. The abort flag is used in place of the transport_generic_free_cmd function call in the reset and timeout cases, because calling that function in that context would free memory that was in use. The aborted flag allows the lifetime to be managed in a more normal way, while truncating the processing. This change eliminates a source of memory corruption which manifested in a variety of ugly ways. (nab: Drop unused struct fc_exch *ep in ft_recv_seq) Signed-off-by:
-
Ludovic Desroches authored
commit 66292ad9 upstream. The HSMCI operates at a rate of up to Master Clock divided by two. Moreover previous calculation can cause overflows and so wrong timeouts. Signed-off-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
Chris Ball <cjb@laptop.org> Signed-off-by:
-
Alf Høgemark authored
commit 8c2fc8e4 upstream. This patch fixes a compile error in drivers/mmc/host/sdhci-dove.c by including the linux/module.h file. Signed-off-by:
Alf Høgemark <alf@i100.no> Signed-off-by:
-
Stephen Warren authored
[no upstream commit match, as this is a fix for a mis-applied patch in the previous 3.2-stable release. - gregkh] Commit 83e41946 "ARM: tegra: select required CPU and L2 errata options" contained two chunks; one was errata for Tegra20 (correctly applied) and the second errata for Tegra30. The latter was accidentally applied to the wrong config option; Tegra30 support wasn't added until v3.3, and so the second chunk should have just been dropped. This patch does so. Signed-off-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
-
Pavel Shilovsky authored
commit 66189be7 upstream. We can deadlock if we have a write oplock and two processes use the same file handle. In this case the first process can't unlock its lock if the second process blocked on the lock in the same time. Fix it by using posix_lock_file rather than posix_lock_file_wait under cinode->lock_mutex. If we request a blocking lock and posix_lock_file indicates that there is another lock that prevents us, wait untill that lock is released and restart our call. Acked-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Pavel Shilovsky <piastry@etersoft.ru> Signed-off-by:
Steve French <sfrench@us.ibm.com> Signed-off-by:
-
Jason Wessel authored
commit 3751d3e8 upstream. There has long been a limitation using software breakpoints with a kernel compiled with CONFIG_DEBUG_RODATA going back to 2.6.26. For this particular patch, it will apply cleanly and has been tested all the way back to 2.6.36. The kprobes code uses the text_poke() function which accommodates writing a breakpoint into a read-only page. The x86 kgdb code can solve the problem similarly by overriding the default breakpoint set/remove routines and using text_poke() directly. The x86 kgdb code will first attempt to use the traditional probe_kernel_write(), and next try using a the text_poke() function. The break point install method is tracked such that the correct break point removal routine will get called later on. Cc: x86@kernel.org Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Inspried-by:
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by:
Jason Wessel <jason.wessel@windriver.com> Signed-off-by:
-
Jason Wessel authored
commit 23bbd8e3 upstream. The do_fork and sys_open tests have never worked properly on anything other than a UP configuration with the kgdb test suite. This is because the test suite did not fully implement the behavior of a real debugger. A real debugger tracks the state of what thread it asked to single step and can correctly continue other threads of execution or conditionally stop while waiting for the original thread single step request to return. Below is a simple method to cause a fatal kernel oops with the kgdb test suite on a 2 processor ARM system: while [ 1 ] ; do ls > /dev/null 2> /dev/null; done& while [ 1 ] ; do ls > /dev/null 2> /dev/null; done& echo V1I1F100 > /sys/module/kgdbts/parameters/kgdbts Very soon after starting the test the kernel will start warning with messages like: kgdbts: BP mismatch c002487c expected c0024878 ------------[ cut here ]------------ WARNING: at drivers/misc/kgdbts.c:317 check_and_rewind_pc+0x9c/0xc4() [<c01f6520>] (check_and_rewind_pc+0x9c/0xc4) [<c01f595c>] (validate_simple_test+0x3c/0xc4) [<c01f60d4>] (run_simple_test+0x1e8/0x274) The kernel will eventually recovers, but the test suite has completely failed to test anything useful. This patch implements behavior similar to a real debugger that does not rely on hardware single stepping by using only software planted breakpoints. In order to mimic a real debugger, the kgdb test suite now tracks the most recent thread that was continued (cont_thread_id), with the intent to single step just this thread. When the response to the single step request stops in a different thread that hit the original break point that thread will now get continued, while the debugger waits for the thread with the single step pending. Here is a high level description of the sequence of events. cont_instead_of_sstep = 0; 1) set breakpoint at do_fork 2) continue 3) Save the thread id where we stop to cont_thread_id 4) Remove breakpoint at do_fork 5) Reset the PC if needed depending on kernel exception type 6) soft single step 7) Check where we stopped if current thread != cont_thread_id { if (here for more than 2 times for the same thead) { ### must be a really busy system, start test again ### goto step 1 } goto step 5 } else { cont_instead_of_sstep = 0; } 8) clean up and run test again if needed 9) Clear out any threads that were waiting on a break point at the point in time the test is ended with get_cont_catch(). This happens sometimes because breakpoints are used in place of single stepping and some threads could have been in the debugger exception handling queue because breakpoints were hit concurrently on different CPUs. This also means we wait at least one second before unplumbing the debugger connection at the very end, so as respond to any debug threads waiting to be serviced. Signed-off-by:
-
Jason Wessel authored
commit 486c5987 upstream. The do_fork and sys_open tests have never worked properly on anything other than a UP configuration with the kgdb test suite. This is because the test suite did not fully implement the behavior of a real debugger. A real debugger tracks the state of what thread it asked to single step and can correctly continue other threads of execution or conditionally stop while waiting for the original thread single step request to return. Below is a simple method to cause a fatal kernel oops with the kgdb test suite on a 4 processor x86 system: while [ 1 ] ; do ls > /dev/null 2> /dev/null; done& while [ 1 ] ; do ls > /dev/null 2> /dev/null; done& while [ 1 ] ; do ls > /dev/null 2> /dev/null; done& while [ 1 ] ; do ls > /dev/null 2> /dev/null; done& echo V1I1F1000 > /sys/module/kgdbts/parameters/kgdbts Very soon after starting the test the kernel will oops with a message like: kgdbts: BP mismatch 3b7da66480 expected ffffffff8106a590 WARNING: at drivers/misc/kgdbts.c:303 check_and_rewind_pc+0xe0/0x100() Call Trace: [<ffffffff812994a0>] check_and_rewind_pc+0xe0/0x100 [<ffffffff81298945>] validate_simple_test+0x25/0xc0 [<ffffffff81298f77>] run_simple_test+0x107/0x2c0 [<ffffffff81298a18>] kgdbts_put_char+0x18/0x20 The warn will turn to a hard kernel crash shortly after that because the pc will not get properly rewound to the right value after hitting a breakpoint leading to a hard lockup. This change is broken up into 2 pieces because archs that have hw single stepping (2.6.26 and up) need different changes than archs that do not have hw single stepping (3.0 and up). This change implements the correct behavior for an arch that supports hw single stepping. A minor defect was fixed where sys_open should be do_sys_open for the sys_open break point test. This solves the problem of running a 64 bit with a 32 bit user space. The sys_open() never gets called when using the 32 bit file system for the kgdb testsuite because the 32 bit binaries invoke the compat_sys_open() call leading to the test never completing. In order to mimic a real debugger, the kgdb test suite now tracks the most recent thread that was continued (cont_thread_id), with the intent to single step just this thread. When the response to the single step request stops in a different thread that hit the original break point that thread will now get continued, while the debugger waits for the thread with the single step pending. Here is a high level description of the sequence of events. cont_instead_of_sstep = 0; 1) set breakpoint at do_fork 2) continue 3) Save the thread id where we stop to cont_thread_id 4) Remove breakpoint at do_fork 5) Reset the PC if needed depending on kernel exception type 6) if (cont_instead_of_sstep) { continue } else { single step } 7) Check where we stopped if current thread != cont_thread_id { cont_instead_of_sstep = 1; goto step 5 } else { cont_instead_of_sstep = 0; } 8) clean up and run test again if needed Signed-off-by:
-
Jason Wessel authored
commit 456ca7ff upstream. On x86 the kgdb test suite will oops when the kernel is compiled with CONFIG_DEBUG_RODATA and you run the tests after boot time. This is regression has existed since 2.6.26 by commit: b33cb815 (kgdbts: Use HW breakpoints with CONFIG_DEBUG_RODATA). The test suite can use hw breakpoints for all the tests, but it has to execute the hardware breakpoint specific tests first in order to determine that the hw breakpoints actually work. Specifically the very first test causes an oops: # echo V1I1 > /sys/module/kgdbts/parameters/kgdbts kgdb: Registered I/O driver kgdbts. kgdbts:RUN plant and detach test Entering kdb (current=0xffff880017aa9320, pid 1078) on processor 0 due to Keyboard Entry [0]kdb> kgdbts: ERROR PUT: end of test buffer on 'plant_and_detach_test' line 1 expected OK got $E14#aa WARNING: at drivers/misc/kgdbts.c:730 run_simple_test+0x151/0x2c0() [...oops clipped...] This commit re-orders the running of the tests and puts the RODATA check into its own function so as to correctly avoid the kernel oops by detecting and using the hw breakpoints. Signed-off-by:
-
Jason Wessel authored
commit 98b54aa1 upstream. There is extra state information that needs to be exposed in the kgdb_bpt structure for tracking how a breakpoint was installed. The debug_core only uses the the probe_kernel_write() to install breakpoints, but this is not enough for all the archs. Some arch such as x86 need to use text_poke() in order to install a breakpoint into a read only page. Passing the kgdb_bpt structure to kgdb_arch_set_breakpoint() and kgdb_arch_remove_breakpoint() allows other archs to set the type variable which indicates how the breakpoint was installed. Signed-off-by:
-
Martin Svec authored
commit 67236c44 upstream. This patch fixes a bug in target-core where unsupported WRITE_SAME ops from a target_check_write_same_discard() failure was incorrectly returning CHECK_CONDITION w/ TCM_INVALID_CDB_FIELD sense data. This was causing some clients to not properly fall back, so go ahead and use the correct TCM_UNSUPPORTED_SCSI_OPCODE sense for this case. Reported-by:
Martin Svec <martin.svec@zoner.cz> Signed-off-by:
-
françois romieu authored
commit 2a15cd2f upstream. With runtime PM, if the ethernet cable is disconnected, the device is transitioned to D3 state to conserve energy. If the system is shutdown in this state, any register accesses in rtl_shutdown are dropped on the floor. As the device was programmed by .runtime_suspend() to wake on link changes, it is thus brought back up as soon as the link recovers. Resuming every suspended device through the driver core would slow things down and it is not clear how many devices really need it now. Original report and D0 transition patch by Sameer Nanda. Patch has been changed to comply with advices by Rafael J. Wysocki and the PM folks. Reported-by:
Sameer Nanda <snanda@chromium.org> Signed-off-by:
Francois Romieu <romieu@fr.zoreil.com> Cc: Rafael J. Wysocki <rjw@sisk.pl> Cc: Hayes Wang <hayeswang@realtek.com> Cc: Alan Stern <stern@rowland.harvard.edu> Acked-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
-
Daniel Vetter authored
commit 25e341cf upstream. Somehow the BIOS manages to screw things up when copying the VBT around, because the one we scrap from the VBIOS rom actually works. Tested-by:
Markus Heinz <markus.heinz@uni-dortmund.de> Acked-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28812Signed-Off-by:
-
Sean Paul authored
commit 927a2f11 upstream. i915_drm_thaw was not locking the mode_config lock when calling drm_helper_resume_force_mode. When there were multiple wake sources, this caused FDI training failure on SNB which in turn corrupted the display. Signed-off-by:
Sean Paul <seanpaul@chromium.org> Reviewed-by:
-
Chris Wilson authored
commit f47166d2 upstream. Quoting the BSpec from time immemorial: PIPEACONF, bits 28:27: Frame Start Delay (Debug) Used to delay the frame start signal that is sent to the display planes. Care must be taken to insure that there are enough lines during VBLANK to support this setting. An instance of the BIOS leaving these bits set was found in the wild, where it caused our modesetting to go all squiffy and skewiff. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47271Reported-and-tested-by:
Eva Wang <evawang@linpus.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43012Reported-and-tested-by:
Carl Richell <carl@system76.com> Signed-off-by:
-
Anisse Astier authored
commit 97effadb upstream. This hardware doesn't have an LVDS, it's a desktop box. Fix incorrect LVDS detection. Signed-off-by:
Anisse Astier <anisse@astier.eu> Acked-by:
-
