14 Apr, 2012
1 commit
13 Apr, 2012
39 commits
-
commit 18daf1644e634bae951a6e3d4d19d89170209762 upstream
Commit 330605423c 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
Tested-by: Daniel Wagner
Acked-by: Marcel Holtmann
Signed-off-by: Johan Hedberg -
commit 9ddd592a191b32f2ee6c4b6ed2bd52665c3a49f5 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 -
commit 79549c6dfda0603dba9a70a53467ce62d9335c33 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
Acked-by: David Howells
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 1f99e44cf059d2ed43c5a0724fa738b83800f725 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 itSigned-off-by: Kuninori Morimoto
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 275029353953c2117941ade84f02a2303912fad1 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
Reported-by: William Dauchy
Tested-by: William Dauchy
Tested-by: Dave Jiang
Signed-off-by: Dan Williams
Signed-off-by: Greg Kroah-Hartman -
commit a2daf263107ba3eb6db33931881731fa51c95045 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
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 3f8349e6e98ba0455437724589072523865eae5e 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
Signed-off-by: Nishanth Menon
Signed-off-by: Samuel Ortiz
Signed-off-by: Greg Kroah-Hartman -
commit 9993bc635d01a6ee7f6b833b4ee65ce7c06350b1 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
Acked-by: John Stultz
Acked-by: Peter Zijlstra
Cc: Paul Turner
Cc: john stultz
Link: http://lkml.kernel.org/r/20120310004027.19291.88460.stgit@dungbeetle.mtv.corp.google.com
Signed-off-by: Ingo Molnar
Cc: Mike Galbraith
Signed-off-by: Greg Kroah-Hartman -
commit 20e0fa98b751facf9a1101edaefbc19c82616a68 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
Signed-off-by: Trond Myklebust
Cc: Josh Boyer
Signed-off-by: Greg Kroah-Hartman -
commit 5719b81988f3c24ff694dc3a37e35b35630a3966 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
Cc: Matthew Garrett
Cc: Mattia Dongili
Cc: Dimitris N
Tested-by: Dimitris N
Signed-off-by: Lee, Chun-Yi
Signed-off-by: Matthew Garrett
Signed-off-by: Greg Kroah-Hartman -
This reverts commit 273fb194e86b795b08a724c7646d0f694949070b
[73d63d038ee9f769f5e5b46792d227fe20e442c5 upstream]It causes problems, so needs to be reverted from 3.2-stable for now.
Reported-by: Konrad Rzeszutek Wilk
Cc: Jon Dufresne
Cc: Suresh Siddha
Cc:
Cc: Josh Boyer
Cc: Ingo Molnar
Cc: Teck Choon Giam
Cc: Ben Guthro
Signed-off-by: Greg Kroah-Hartman -
commit df91e49477a9be15921cb2854e1d12a3bdb5e425 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
Signed-off-by: James Morris
Signed-off-by: Greg Kroah-Hartman -
commit a97f4f5e524bcd09a85ef0b8821a14d35e69335f 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 .Reported-by: Carlos Luna
Reviewed-by: Bjorn Helgaas
Signed-off-by: Jonathan Nieder
Signed-off-by: Jesse Barnes
Signed-off-by: Greg Kroah-Hartman -
commit 8411371709610c826bf65684f886bfdfb5780ca1 upstream.
In the spirit of commit 29cf7a30f8a0 ("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 3e3da00c01d0
("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 updateIn 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=42619
Reported-by: Svante Signell
Signed-off-by: Jonathan Nieder
Signed-off-by: Bjorn Helgaas
Signed-off-by: Jesse Barnes
Signed-off-by: Greg Kroah-Hartman -
commit 258f742635360175564e9470eb060ff4d4b984e7 upstream.
Commit f02e8a6596b7 ("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 62a2635610db ("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
Signed-off-by: Alessio Igor Bogani
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 620f6e8e855d6d447688a5f67a4e176944a084e8 upstream.
Commit bfdc0b4 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
Signed-off-by: Kees Cook
Acked-by: Serge Hallyn
Acked-by: Richard Weinberger
Signed-off-by: James Morris
Signed-off-by: Greg Kroah-Hartman -
commit 06383f10c49f507220594a455c6491ca6f8c94ab 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
Acked-by: Kiran Patil
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
commit e1c4038282c7586c3544542b37872c434669d3ac 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: Mark Rustad
Acked-by: Kiran Patil
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
commit 66292ad92c6d3f2f1c137a1c826b331ca8595dfd 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
Acked-by: Nicolas Ferre
Signed-off-by: Chris Ball
Signed-off-by: Greg Kroah-Hartman -
commit 8c2fc8e413ecc2c96b696e28d4eb1bc6cee8dc84 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
Signed-off-by: Chris Ball
Signed-off-by: Greg Kroah-Hartman -
[no upstream commit match, as this is a fix for a mis-applied patch in the
previous 3.2-stable release. - gregkh]Commit 83e4194 "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
Signed-off-by: Greg Kroah-Hartman -
commit 66189be74ff5f9f3fd6444315b85be210d07cef2 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
Signed-off-by: Pavel Shilovsky
Signed-off-by: Steve French
Signed-off-by: Greg Kroah-Hartman -
commit 3751d3e85cf693e10e2c47c03c8caa65e171099b 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
Cc: Ingo Molnar
Cc: H. Peter Anvin
Inspried-by: Masami Hiramatsu
Signed-off-by: Jason Wessel
Signed-off-by: Greg Kroah-Hartman -
commit 23bbd8e346f1ef3fc1219c79cea53d8d52b207d8 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/kgdbtsVery 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()
[] (check_and_rewind_pc+0x9c/0xc4)
[] (validate_simple_test+0x3c/0xc4)
[] (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
Signed-off-by: Greg Kroah-Hartman -
commit 486c5987a00a89d56c2c04c506417ef8f823ca2e 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/kgdbtsVery 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:
[] check_and_rewind_pc+0xe0/0x100
[] validate_simple_test+0x25/0xc0
[] run_simple_test+0x107/0x2c0
[] kgdbts_put_char+0x18/0x20The 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 neededSigned-off-by: Jason Wessel
Signed-off-by: Greg Kroah-Hartman -
commit 456ca7ff24841bf2d2a2dfd690fe7d42ef70d932 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 testEntering 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
Signed-off-by: Greg Kroah-Hartman -
commit 98b54aa1a2241b59372468bd1e9c2d207bdba54b 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: Jason Wessel
Signed-off-by: Greg Kroah-Hartman -
commit 67236c44741e250199ccd77f1115568e68cf8848 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
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
commit 2a15cd2ff488a9fdb55e5e34060f499853b27c77 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
Signed-off-by: Francois Romieu
Cc: Rafael J. Wysocki
Cc: Hayes Wang
Cc: Alan Stern
Acked-by: Rafael J. Wysocki
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 25e341cfc33d94435472983825163e97fe370a6c 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
Acked-by: Chris Wilson
Reviewed-by: Rodrigo Vivi
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28812
Signed-Off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit 927a2f119e8235238a2fc64871051b16c9bdae75 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
Reviewed-by: Chris Wilson
Signed-Off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit f47166d2b0001fcb752b40c5a2d4db986dfbea68 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=47271
Reported-and-tested-by: Eva Wang
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43012
Reported-and-tested-by: Carl Richell
Signed-off-by: Chris Wilson
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit 97effadb65ed08809e1720c8d3ee80b73a93665c upstream.
This hardware doesn't have an LVDS, it's a desktop box. Fix incorrect
LVDS detection.Signed-off-by: Anisse Astier
Acked-by: Chris Wilson
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit 402976fe51b2d1a58a29ba06fa1ca5ace3a4cdcd upstream.
On pre-R600 asics, the SpeedFanControl table is not
executed as part of ASIC_Init as it is on newer asics.Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=29412Signed-off-by: Alex Deucher
Reviewed-by: Michel Dänzer
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit 62fb376e214d3c1bfdf6fbb77dac162f6da04d7e upstream.
mplayer -vo fbdev tries to create a screen that is twice as tall as the
allocated framebuffer for "doublebuffering". By default, and all in-tree
users, only sufficient memory is allocated and mapped to satisfy the
smallest framebuffer and the virtual size is no larger than the actual.
For these users, we should therefore reject any userspace request to
create a screen that requires a buffer larger than the framebuffer
originally allocated.References: https://bugs.freedesktop.org/show_bug.cgi?id=38138
Signed-off-by: Chris Wilson
Reviewed-by: Daniel Vetter
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit 643c61e119459e9d750087b7b34be94491efebf9 upstream.
In https://bugzilla.redhat.com/show_bug.cgi?id=770207, slowdowns of driver
rtl8192ce are reported. One fix (commit a9b89e2) has already been applied,
and it helped, but the maximum RX speed would still drop to 1 Mbps. As in
the previous fix, the initial gain was determined to be the problem; however,
the problem arises from a setting of the gain when scans are started.Driver rtl8192de also has the same code structure - this one is fixed as well.
Reported-and-Tested-by: Ivan Pesin
Signed-off-by: Larry Finger
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit d72308bff5c2fa207949a5925b020bce74495e33 upstream.
Is possible that we will arm the tid_rx->reorder_timer after
del_timer_sync() in ___ieee80211_stop_rx_ba_session(). We need to stop
timer after RCU grace period finish, so move it to
ieee80211_free_tid_rx(). Timer will not be armed again, as
rcu_dereference(sta->ampdu_mlme.tid_rx[tid]) will return NULL.Debug object detected problem with the following warning:
ODEBUG: free active (active state 0) object type: timer_list hint: sta_rx_agg_reorder_timer_expired+0x0/0xf0 [mac80211]Bug report (with all warning messages):
https://bugzilla.redhat.com/show_bug.cgi?id=804007Reported-by: "jan p. springer"
Signed-off-by: Stanislaw Gruszka
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit 6cfeba53911d6d2f17ebbd1246893557d5ff5aeb upstream.
On multi-platform kernels, the Mac platform devices should be registered
when running on Mac only. Else it may crash later.Signed-off-by: Geert Uytterhoeven
Signed-off-by: Greg Kroah-Hartman -
commit 12b5da349a8b94c9dbc3430a6bc42eabd9eaf50b upstream.
When reading the trace file, the records of each of the per_cpu buffers
are examined to find the next event to print out. At the point of looking
at the event, the size of the event is recorded. But if the first event is
chosen, the other events in the other CPU buffers will reset the event size
that is stored in the iterator descriptor, causing the event size passed to
the output functions to be incorrect.In most cases this is not a problem, but for the case of stack traces, it
is. With the change to the stack tracing to record a dynamic number of
back traces, the output depends on the size of the entry instead of the
fixed 8 back traces. When the entry size is not correct, the back traces
would not be fully printed.Note, reading from the per-cpu trace files were not affected.
Reported-by: Thomas Gleixner
Tested-by: Thomas Gleixner
Signed-off-by: Steven Rostedt
Signed-off-by: Greg Kroah-Hartman
