- 22 Dec, 2014 26 commits
-
-
Roland Dreier authored
If an initiator sends a zero-length command (e.g. TEST UNIT READY) but sets the transfer direction in the transport layer to indicate a data-out phase, we still shouldn't try to transfer data. At best it's a NOP, and depending on the transport, we might crash on an uninitialized sg list. Reported-by:
Craig Watson <craig.watson@vanguard-rugged.com> Signed-off-by:
Roland Dreier <roland@purestorage.com> Cc: <stable@vger.kernel.org> # 3.1 Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> (cherry picked from commit 885e7b0e) Signed-off-by:
Sasha Levin <sasha.levin@oracle.com>
-
Bart Van Assche authored
It is not guaranteed to that srp_sq_size is supported by the HCA. So if we failed to create the QP with ENOMEM, try with a smaller srp_sq_size. Keep it up until we hit MIN_SRPT_SQ_SIZE, then fail the connection. Reported-by:
Mark Lehrer <lehrer@gmail.com> Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Sagi Grimberg <sagig@mellanox.com> Cc: <stable@vger.kernel.org> # 3.4+ Signed-off-by:
-
Greg Kroah-Hartman authored
The xpad wireless endpoint is not a bulk endpoint on my devices, but rather an interrupt one, so the USB core complains when it is submitted. I'm guessing that the author really did mean that this should be an interrupt urb, but as there are a zillion different xpad devices out there, let's cover out bases and handle both bulk and interrupt endpoints just as easily. Signed-off-by:
"Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: stable <stable@vger.kernel.org> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> (cherry picked from commit a1f9a407) Signed-off-by:
-
Thomas Petazzoni authored
Under extremely rare conditions, in an MPCore node consisting of at least 3 CPUs, two CPUs trying to perform a STREX to data on the same shared cache line can enter a livelock situation. This patch enables the HW mechanism that overcomes the bug. This fixes the incorrect setup of the STREX backoff delay bit due to a wrong description in the specification. Note that enabling the STREX backoff delay mechanism is done by leaving the bit *cleared*, while the bit was currently being set by the proc-v7.S code. [Thomas: adapt to latest mainline, slightly reword the commit log, add stable markers.] Fixes: de490193 ("arm: mm: Add support for PJ4B cpu and init routines") Cc: <stable@vger.kernel.org> # v3.8+ Signed-off-by:
Nadav Haklai <nadavh@marvell.com> Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Acked-by:
Jason Cooper <jason@lakedaemon.net> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> (cherry picked from commit 995ab518) Signed-off-by:
-
Dmitry Eremin-Solenikov authored
According to the manuals I have, XScale auxiliary register should be reached with opc_2 = 1 instead of crn = 1. cpu_xscale_proc_init correctly uses c1, c0, 1 arguments, but cpu_xscale_do_suspend and cpu_xscale_do_resume use c1, c1, 0. Correct suspend/resume functions to also use c1, c0, 1. The issue was primarily noticed thanks to qemu reporing "unsupported instruction" on the pxa suspend path. Confirmed in PXA210/250 and PXA255 XScale Core manuals and in PXA270 and PXA320 Developers Guides. Harware tested by me on tosa (pxa255). Robert confirmed on pxa270 board. Tested-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Acked-by:
-
Lv Zheng authored
commit 558e4736 upstream. There is platform refusing to respond QR_EC when SCI_EVT isn't set which is Acer Aspire V5-573G. By disallowing QR_EC to be issued before the previous one has been completed we are able to reduce the possibilities to trigger issues on such platforms. Note that this fix can only reduce the occurrence rate of this issue, but this issue may still occur when such a platform doesn't clear SCI_EVT before or immediately after completing the previous QR_EC transaction. This patch cannot fix the CLEAR_ON_RESUME quirk which also relies on the assumption that the platforms are able to respond even when SCI_EVT isn't set. But this patch is still useful as it can help to reduce the number of scheduled QR_EC work items. Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611Reported-and-tested-by:
Alexander Mezin <mezin.alexander@gmail.com> Signed-off-by:
Lv Zheng <lv.zheng@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Jurgen Kramer authored
This patch adds a USB control message delay quirk for a few specific Marantz/Denon devices. Without the delay the DACs will not work properly and produces the following type of messages: Nov 15 10:09:21 orwell kernel: [ 91.342880] usb 3-13: clock source 41 is not valid, cannot use Nov 15 10:09:21 orwell kernel: [ 91.343775] usb 3-13: clock source 41 is not valid, cannot use There are likely other Marantz/Denon devices using the same USB module which exhibit the same problems. But as this cannot be verified I limited the patch to the devices I could test. The following two devices are covered by this path: - Marantz SA-14S1 - Marantz HD-DAC1 Signed-off-by:
Jurgen Kramer <gtmkramer@xs4all.nl> Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> (cherry picked from commit 6e84a8d7) Signed-off-by:
-
Alexey Khoroshilov authored
It seems struct esd_usb2 dev is not deallocated on disconnect. The patch adds the missing deallocation. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Acked-by:
Matthias Fuchs <matthias.fuchs@esd.eu> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> (cherry picked from commit efbd50d2) Signed-off-by:
-
Mathias Nyman authored
A halted endpoint ring must first be reset, then move the ring dequeue pointer past the problematic TRB. If we start the ring too early after reset, but before moving the dequeue pointer we will end up executing the same problematic TRB again. As we always issue a set transfer dequeue command after a reset endpoint command we can skip starting endpoint rings at reset endpoint command completion. Without this fix we end up trying to handle the same faulty TD for contol endpoints. causing timeout, and failing testusb ctrl_out write tests. Fixes: e9df17eb (USB: xhci: Correct assumptions about number of rings per endpoint.) Cc: <stable@vger.kernel.org> #v2.6.35 Tested-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Hans de Goede authored
This wireless mouse receiver needs a reset-resume quirk to properly come out of reset. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1165206Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Troy Clark authored
Add PIDs for new Matrix Orbital GTT series products. Signed-off-by:
Troy Clark <tclark@matrixorbital.ca> Cc: stable <stable@vger.kernel.org> [johan: shorten commit message ] Signed-off-by:
Johan Hovold <johan@kernel.org> (cherry picked from commit 204ec6e0) Signed-off-by:
-
Preston Fick authored
Signed-off-by:
Preston Fick <pffick@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Cristina Ciocan authored
The direction field is set on 7 bits, thus we need to AND it with 0111 111 mask in order to retrieve it, that is 0x7F, not 0xCF as it is now. Fixes: ade7ef7b (staging:iio: Differential channel handling) Signed-off-by:
Cristina Ciocan <cristina.ciocan@intel.com> Cc: <Stable@vger.kernel.org> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> (cherry picked from commit ccf54555) Signed-off-by:
-
Laurent Dufour authored
On pseries system (LPAR) xmon failed to enter when running in LE mode, system is hunging. Inititating xmon will lead to such an output on the console: SysRq : Entering xmon cpu 0x15: Vector: 0 at [c0000003f39ffb10] pc: c00000000007ed7c: sysrq_handle_xmon+0x5c/0x70 lr: c00000000007ed7c: sysrq_handle_xmon+0x5c/0x70 sp: c0000003f39ffc70 msr: 8000000000009033 current = 0xc0000003fafa7180 paca = 0xc000000007d75e80 softe: 0 irq_happened: 0x01 pid = 14617, comm = bash Bad kernel stack pointer fafb4b0 at eca7cc4 cpu 0x15: Vector: 300 (Data Access) at [c000000007f07d40] pc: 000000000eca7cc4 lr: 000000000eca7c44 sp: fafb4b0 msr: 8000000000001000 dar: 10000000 dsisr: 42000000 current = 0xc0000003fafa7180 paca = 0xc000000007d75e80 softe: 0 irq_happened: 0x01 pid = 14617, comm = bash cpu 0x15: Exception 300 (Data Access) in xmon, returning to main loop xmon: WARNING: bad recursive fault on cpu 0x15 The root cause is that xmon is calling RTAS to turn off the surveillance when entering xmon, and RTAS is requiring big endian parameters. This patch is byte swapping the RTAS arguments when running in LE mode. Cc: stable@vger.kernel.org Signed-off-by:Laurent Dufour <ldufour@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> (cherry picked from commit 3b8a3c01) Signed-off-by:
-
Benjamin Herrenschmidt authored
We have a historical hack that treats missing ranges properties as the equivalent of an empty one. This is needed for ancient PowerMac "bad" device-trees, and shouldn't be enabled for any other PowerPC platform, otherwise we get some nasty layout of devices in sysfs or even duplication when a set of otherwise identically named devices is created multiple times under a different parent node with no ranges property. This fix is needed for the PowerNV i2c busses to be exposed properly and will fix a number of other embedded cases. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: <stable@vger.kernel.org> Acked-by:
Grant Likely <grant.likely@linaro.org> Signed-off-by:
Rob Herring <robh@kernel.org> (cherry picked from commit 746c9e9f) Signed-off-by:
-
Charles Keepax authored
We should not free any buffers associated with writing out coefficients to the DSP until all the async writes have completed. This patch updates the out of memory path when allocating a new buffer to include a call to regmap_async_complete. Reported-by:
JS Park <aitdark.park@samsung.com> Signed-off-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org (cherry picked from commit 9da7a5a9) Signed-off-by:
-
Fabio Estevam authored
On a mx28evk with a sgtl5000 codec we notice a loud 'click' sound to happen 5 seconds after the end of a playback. The SMALL_POP bit should fix this, but its definition is incorrect: according to the sgtl5000 manual it is bit 0 of CHIP_REF_CTRL register, not bit 1. Fix the definition accordingly and enable the bit as intended per the code comment. After applying this change, no loud 'click' sound is heard after playback Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by:
-
Andy Lutomirski authored
x86 call do_notify_resume on paranoid returns if TIF_UPROBE is set but not on non-paranoid returns. I suspect that this is a mistake and that the code only works because int3 is paranoid. Setting _TIF_NOTIFY_RESUME in the uprobe code was probably a workaround for the x86 bug. With that bug fixed, we can remove _TIF_NOTIFY_RESUME from the uprobes code. Reported-by:
Oleg Nesterov <oleg@redhat.com> Acked-by:
Srikar Dronamraju <srikar@linux.vnet.ibm.com> Acked-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
Andy Lutomirski <luto@amacapital.net> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 82975bc6) Signed-off-by:
-
Dave Hansen authored
We have some very similarly named command-line options: arch/x86/kernel/cpu/common.c:__setup("noxsave", x86_xsave_setup); arch/x86/kernel/cpu/common.c:__setup("noxsaveopt", x86_xsaveopt_setup); arch/x86/kernel/cpu/common.c:__setup("noxsaves", x86_xsaves_setup); __setup() is designed to match options that take arguments, like "foo=bar" where you would have: __setup("foo", x86_foo_func...); The problem is that "noxsave" actually _matches_ "noxsaves" in the same way that "foo" matches "foo=bar". If you boot an old kernel that does not know about "noxsaves" with "noxsaves" on the command line, it will interpret the argument as "noxsave", which is not what you want at all. This makes the "noxsave" handler only return success when it finds an *exact* match. [ tglx: We really need to make __setup() more robust. ] Signed-off-by:Dave Hansen <dave.hansen@linux.intel.com> Cc: Dave Hansen <dave@sr71.net> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: x86@kernel.org Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/20141111220133.FE053984@viggo.jf.intel.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> (cherry picked from commit 2cd3949f) Signed-off-by:
-
Aaro Koskinen authored
If SERIAL_8250 is compiled as a module, the platform specific setup for Loongson will be a module too, and it will not work very well. At least on Loongson 3 it will trigger a build failure, since loongson_sysconf is not exported to modules. Fix by making the platform specific serial code always built-in. Signed-off-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Reported-by:
Ralf Baechle <ralf@linux-mips.org> Cc: stable@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: Huacai Chen <chenhc@lemote.com> Cc: Markos Chandras <Markos.Chandras@imgtec.com> Patchwork: https://patchwork.linux-mips.org/patch/8533/Signed-off-by:
-
Leonid Yegoshin authored
There is a potential race when probing the TLB in TLBL/M/S exception handlers for a matching entry. Between the time we hit a TLBL/S/M exception and the time we get to execute the TLBP instruction, the HTW may have replaced the TLB entry we are interested in hence the TLB probe may fail. However, in the existing handlers, we never checked the status of the TLBP (ie check the result in the C0/Index register). We fix this by adding such a check when the core implements the HTW. If we couldn't find a matching entry, we return back and try again. Signed-off-by:
Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Signed-off-by:
Markos Chandras <markos.chandras@imgtec.com> Reviewed-by:
James Hogan <james.hogan@imgtec.com> Cc: <stable@vger.kernel.org> # v3.17+ Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/8599/Signed-off-by:
-
Markos Chandras authored
Commit de8974e3 ("MIPS: asm: r4kcache: Add EVA cache flushing functions") added cache function for EVA using the cachee instruction. However, it didn't add a case for the protected_writeback_dcache_line. mips_dsemul() calls r4k_flush_cache_sigtramp() which in turn uses the protected_writeback_dcache_line() to flush the trampoline code back to memory. This used the wrong "cache" instruction leading to random userland crashes on non-FPU cores. Signed-off-by:
-
Markos Chandras authored
When EVA is turned on and prefetching is being used in memcpy.S, the v1 register is being used as a helper register to the PREFE instruction. However, v1 ($3) was not in the clobber list, which means that the compiler did not preserve it across function calls, and that could corrupt the value of the register leading to all sorts of userland crashes. We fix this problem by using the DADDI_SCRATCH macro to define the clobbered register when CONFIG_EVA && CONFIG_CPU_HAS_PREFETCH are enabled. Signed-off-by:
-
Aaro Koskinen authored
Fix incorrect cast that always results in wrong address for the new frame on 64-bit kernels. Signed-off-by:
Aaro Koskinen <aaro.koskinen@nsn.com> Cc: stable@vger.kernel.org Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/8110/Signed-off-by:
-
James Cowgill authored
export the __node_distances symbol in the ip27 memory code to fix the build error: Building modules, stage 2. MODPOST 311 modules ERROR: "__node_distances" [drivers/block/nvme.ko] undefined! scripts/Makefile.modpost:90: recipe for target '__modpost' failed when building the kernel with: CONFIG_SGI_IP27=y CONFIG_BLK_DEV_NVME=m Signed-off-by:
James Cowgill <James.Cowgill@imgtec.com> Cc: <stable@vger.kernel.org> # v3.15+ Reviewed-by:
-
Stanislaw Gruszka authored
X550VB as many others Asus laptops need wapf4 quirk to make RFKILL switch be functional. Otherwise system boots with wireless card disabled and is only possible to enable it by suspend/resume. Bug report: http://bugzilla.redhat.com/show_bug.cgi?id=1089731#c23Reported-and-tested-by:
Vratislav Podzimek <vpodzime@redhat.com> Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
Darren Hart <dvhart@linux.intel.com> (cherry picked from commit 4ec7a45b) Signed-off-by:
-
- 08 Dec, 2014 1 commit
-
-
Sasha Levin authored
Signed-off-by:
-
- 06 Dec, 2014 13 commits
-
-
Willy Tarreau authored
This reverts commit 63d059e7. On Wed, Sep 03, 2014 at 11:28:43AM +1000, NeilBrown wrote: > > 2.6.32.30 contains: > > commit 63d059e7 > Author: NeilBrown <neilb@suse.de> > Date: Wed Feb 16 13:08:35 2011 +1100 > > nfsd: correctly handle return value from nfsd_map_name_to_* > > commit 47c85291 upstream. > > These functions return an nfs status, not a host_err. So don't > try to convert before returning. > > This is a regression introduced by > 3c726023; I fixed up two of the callers, > but missed these two. > > Reported-by: Herbert Poetzl <herbert@13thfloor.at> > Signed-off-by: NeilBrown <neilb@suse.de> > Signed-off-by: J. Bruce Fields <bfields@redhat.com> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> > > > But it does *not* contain a backport of > 3c726023. > > So rather an fixing a regression, it introduces one. > > This patch should be reverted. > > See also https://bugzilla.novell.com/show_bug.cgi?id=893787 > > NeilBrown Signed-off-by:
Willy Tarreau <w@1wt.eu> (cherry picked from commit 5e4b587d) (cherry picked from commit HEAD) Signed-off-by:
-
Stefan Bader authored
commit 554086d8 "x86_32, entry: Do syscall exit work on badsys (CVE-2014-4508)" introduced a new jump label (sysenter_badsys) but somehow the END statements seem to have gone wrong (at least it feels that way to me). This does not seem to be a fatal problem, but just for the sake of symmetry, change the second syscall_badsys to sysenter_badsys. Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Link: http://lkml.kernel.org/r/1408093066-31021-1-git-send-email-stefan.bader@canonical.comAcked-by:
H. Peter Anvin <hpa@linux.intel.com> (cherry picked from commit fb21b84e) Signed-off-by:
-
Matthew Leach authored
When copying in a struct msghdr from the user, if the user has set the msg_namelen parameter to a negative value it gets clamped to a valid size due to a comparison between signed and unsigned values. Ensure the syscall errors when the user passes in a negative value. Signed-off-by:
Matthew Leach <matthew.leach@arm.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit dbb490b9) Signed-off-by:
-
Dan Carpenter authored
If kmsg->msg_namelen > sizeof(struct sockaddr_storage) then in the original code that would lead to memory corruption in the kernel if you had audit configured. If you didn't have audit configured it was harmless. There are some programs such as beta versions of Ruby which use too large of a buffer and returning an error code breaks them. We should clamp the ->msg_namelen value instead. Fixes: 1661bf36 ("net: heap overflow in __audit_sockaddr()") Reported-by:
Eric Wong <normalperson@yhbt.net> Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Tested-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Nikola Pajkovsky authored
crypto_larval_lookup should only return a larval if it created one. Any larval created by another entity must be processed through crypto_larval_wait before being returned. Otherwise this will lead to a larval being killed twice, which will most likely lead to a crash. Cc: stable@vger.kernel.org Reported-by:
Kees Cook <keescook@chromium.org> Tested-by:
Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit 77dbd7a9) Signed-off-by:
-
James Bottomley authored
USB surprise removal of sr is triggering an oops in scsi_dispatch_command(). What seems to be happening is that USB is hanging on to a queue reference until the last close of the upper device, so the crash is caused by surprise remove of a mounted CD followed by attempted unmount. The problem is that USB doesn't issue its final commands as part of the SCSI teardown path, but on last close when the block queue is long gone. The long term fix is probably to make sr do the teardown in the same way as sd (so remove all the lower bits on ejection, but keep the upper disk alive until last close of user space). However, the current oops can be simply fixed by not allowing any commands to be sent to a dead queue. Cc: stable@kernel.org Signed-off-by:
James Bottomley <JBottomley@Parallels.com> (cherry picked from commit bfe159a5) Signed-off-by:
-
Oleg Nesterov authored
Minor cleanup. ____call_usermodehelper() can simply return, no need to call do_exit() explicitely. Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Ben Hutchings authored
This reverts commit 2af3af56, which was commit 6c4088ac upstream. This broke compilation of the driver in 2.6.32.y as the early_io{remap,unmap}() functions are not defined for ia64. The driver can *only* be built for ia64 (even in current mainline), so a fix for x86_64 is pointless. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Linus Torvalds authored
Add a new interface, add_device_randomness() for adding data to the random pool that is likely to differ between two devices (or possibly even per boot). This would be things like MAC addresses or serial numbers, or the read-out of the RTC. This does *not* add any actual entropy to the pool, but it initializes the pool to different values for devices that might otherwise be identical and have very little entropy available to them (particularly common in the embedded world). [ Modified by tytso to mix in a timestamp, since there may be some variability caused by the time needed to detect/configure the hardware in question. ] Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Cc: stable@vger.kernel.org (cherry picked from commit a2080a67) Signed-off-by:
-
bjschuma@gmail.com authored
This allows distros to remove the line from their modprobe configuration. Signed-off-by:
Bryan Schumaker <bjschuma@netapp.com> Cc: stable@vger.kernel.org Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> (cherry picked from commit 425e776d) Signed-off-by:
-
Greg Pearson authored
efi_setup_pcdp_console() is called during boot to parse the HCDP/PCDP EFI system table and setup an early console for printk output. The routine uses ioremap/iounmap to setup access to the HCDP/PCDP table information. The call to ioremap is happening early in the boot process which leads to a panic on x86_64 systems: panic+0x01ca do_exit+0x043c oops_end+0x00a7 no_context+0x0119 __bad_area_nosemaphore+0x0138 bad_area_nosemaphore+0x000e do_page_fault+0x0321 page_fault+0x0020 reserve_memtype+0x02a1 __ioremap_caller+0x0123 ioremap_nocache+0x0012 efi_setup_pcdp_console+0x002b setup_arch+0x03a9 start_kernel+0x00d4 x86_64_start_reservations+0x012c x86_64_start_kernel+0x00fe This replaces the calls to ioremap/iounmap in efi_setup_pcdp_console() with calls to early_ioremap/early_iounmap which can be called during early boot. This patch was tested on an x86_64 prototype system which uses the HCDP/PCDP table for early console setup. Signed-off-by:Greg Pearson <greg.pearson@hp.com> Acked-by:
Khalid Aziz <khalid.aziz@hp.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Thomas Jarosch authored
Some BIOS implementations leave the Intel GPU interrupts enabled, even though no one is handling them (f.e. i915 driver is never loaded). Additionally the interrupt destination is not set up properly and the interrupt ends up -somewhere-. These spurious interrupts are "sticky" and the kernel disables the (shared) interrupt line after 100.000+ generated interrupts. Fix it by disabling the still enabled interrupts. This resolves crashes often seen on monitor unplug. Tested on the following boards: - Intel DH61CR: Affected - Intel DH67BL: Affected - Intel S1200KP server board: Affected - Asus P8H61-M LE: Affected, but system does not crash. Probably the IRQ ends up somewhere unnoticed. According to reports on the net, the Intel DH61WW board is also affected. Many thanks to Jesse Barnes from Intel for helping with the register configuration and to Intel in general for providing public hardware documentation. Signed-off-by:
Thomas Jarosch <thomas.jarosch@intra2net.com> Tested-by:
Charlie Suffin <charlie.suffin@stratus.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> (cherry picked from commit f67fd55f) Signed-off-by:
-
OGAWA Hirofumi authored
ratelimit_state initialization of printk_ratelimited() seems broken. This fixes it by using DEFINE_RATELIMIT_STATE() to initialize spinlock properly. Signed-off-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Cc: Joe Perches <joe@perches.com> Signed-off-by:
-
