17 Dec, 2014
35 commits
-
commit 66139a48cee1530c91f37c145384b4ee7043f0b7 upstream.
In snd_usbmidi_error_timer(), the driver tries to resubmit MIDI input
URBs to reactivate the MIDI stream, but this causes the error when
some of URBs are still pending like:WARNING: CPU: 0 PID: 0 at ../drivers/usb/core/urb.c:339 usb_submit_urb+0x5f/0x70()
URB ef705c40 submitted while active
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.6-2-desktop #1
Hardware name: FOXCONN TPS01/TPS01, BIOS 080015 03/23/2010
c0984bfa f4009ed4 c078deaf f4009ee4 c024c884 c09a135c f4009f00 00000000
c0984bfa 00000153 c061ac4f c061ac4f 00000009 00000001 ef705c40 e854d1c0
f4009eec c024c8d3 00000009 f4009ee4 c09a135c f4009f00 f4009f04 c061ac4f
Call Trace:
[] try_stack_unwind+0x156/0x170
[] dump_trace+0x5a/0x1b0
[] show_trace_log_lvl+0x46/0x50
[] show_stack_log_lvl+0x51/0xe0
[] show_stack+0x27/0x50
[] dump_stack+0x45/0x65
[] warn_slowpath_common+0x84/0xa0
[] warn_slowpath_fmt+0x33/0x40
[] usb_submit_urb+0x5f/0x70
[] snd_usbmidi_submit_urb+0x14/0x60 [snd_usbmidi_lib]
[] snd_usbmidi_error_timer+0x6a/0xa0 [snd_usbmidi_lib]
[] call_timer_fn+0x30/0x130
[] run_timer_softirq+0x1c2/0x260
[] __do_softirq+0xc3/0x270
[] do_softirq_own_stack+0x22/0x30
[] irq_exit+0x8d/0xa0
[] smp_apic_timer_interrupt+0x38/0x50
[] apic_timer_interrupt+0x34/0x3c
[] cpuidle_enter_state+0x3e/0xd0
[] cpu_idle_loop+0x29d/0x3e0
[] cpu_startup_entry+0x53/0x60
[] start_kernel+0x415/0x41aFor avoiding these errors, check the pending URBs and skip
resubmitting such ones.Reported-and-tested-by: Stefan Seyfried
Acked-by: Clemens Ladisch
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit fedb2245cbb8d823e449ebdd48ba9bb35c071ce0 upstream.
The built-in mic boost volume gets almost muted after suspend/resume
on Lenovo Ideapad S210.Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88121
Reported-and-tested-by: Roman Kagan
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit f62f5eff3d40a56ad1cf0d81a6cac8dd8743e8a1 upstream.
The same fixup to enable EAPD is needed for ASUS Z99He with AD1986A
codec like another ASUS machine.Reported-and-tested-by: Dmitry V. Zimin
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 4f031fa9f188b2b0641ac20087d9e16bcfb4e49d upstream.
Commit 7ec7c4a9a686c608315739ab6a2b0527a240883c (mac80211: port CCMP to
cryptoapi's CCM driver) introduced a regression when decrypting empty
packets (data_len == 0). This will lead to backtraces like:(scatterwalk_start) from [] (scatterwalk_map_and_copy+0x2c/0xa8)
(scatterwalk_map_and_copy) from [] (crypto_ccm_decrypt+0x7c/0x25c)
(crypto_ccm_decrypt) from [] (ieee80211_aes_ccm_decrypt+0x160/0x170)
(ieee80211_aes_ccm_decrypt) from [] (ieee80211_crypto_ccmp_decrypt+0x1ac/0x238)
(ieee80211_crypto_ccmp_decrypt) from [] (ieee80211_rx_handlers+0x870/0x1d24)
(ieee80211_rx_handlers) from [] (ieee80211_prepare_and_rx_handle+0x8a0/0x91c)
(ieee80211_prepare_and_rx_handle) from [] (ieee80211_rx+0x568/0x730)
(ieee80211_rx) from [] (__carl9170_rx+0x94c/0xa20)
(__carl9170_rx) from [] (carl9170_rx_stream+0x1fc/0x320)
(carl9170_rx_stream) from [] (carl9170_usb_tasklet+0x80/0xc8)
(carl9170_usb_tasklet) from [] (tasklet_hi_action+0x88/0xcc)
(tasklet_hi_action) from [] (__do_softirq+0xcc/0x200)
(__do_softirq) from [] (irq_exit+0x80/0xe0)
(irq_exit) from [] (handle_IRQ+0x64/0x80)
(handle_IRQ) from [] (__irq_svc+0x40/0x4c)
(__irq_svc) from [] (arch_cpu_idle+0x2c/0x34)Such packets can appear for example when using the carl9170 wireless driver
because hardware sometimes generates garbage when the internal FIFO overruns.This patch adds an additional length check.
Fixes: 7ec7c4a9a686 ("mac80211: port CCMP to cryptoapi's CCM driver")
Acked-by: Ard Biesheuvel
Signed-off-by: Ronald Wahl
Signed-off-by: Johannes Berg
Signed-off-by: Greg Kroah-Hartman -
commit 152d44a853e42952f6c8a504fb1f8eefd21fd5fd upstream.
I used some 64 bit instructions when adding the 32 bit getcpu VDSO
function. Fix it.Fixes: 18ad51dd342a ("powerpc: Add VDSO version of getcpu")
Signed-off-by: Anton Blanchard
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman -
commit aec653c43b0c55667355e26d7de1236bda9fb4e3 upstream.
Call igb_setup_link() when the PHY is powered up.
Signed-off-by: Todd Fujinaka
Reported-by: Jeff Westfahl
Tested-by: Aaron Brown
Signed-off-by: Jeff Kirsher
Cc: Vincent Donnefort
Signed-off-by: Greg Kroah-Hartman -
commit 338b522ca43cfd32d11a370f4203bcd089c6c877 upstream.
With -cpu host, KVM reports LBR and extra_regs support, if the host has
support.When the guest perf driver tries to access LBR or extra_regs MSR,
it #GPs all MSR accesses,since KVM doesn't handle LBR and extra_regs support.
So check the related MSRs access right once at initialization time to avoid
the error access at runtime.For reproducing the issue, please build the kernel with CONFIG_KVM_INTEL = y
(for host kernel).
And CONFIG_PARAVIRT = n and CONFIG_KVM_GUEST = n (for guest kernel).
Start the guest with -cpu host.
Run perf record with --branch-any or --branch-filter in guest to trigger LBR
Run perf stat offcore events (E.g. LLC-loads/LLC-load-misses ...) in guest to
trigger offcore_rsp #GPSigned-off-by: Kan Liang
Signed-off-by: Peter Zijlstra
Cc: Andi Kleen
Cc: Arnaldo Carvalho de Melo
Cc: Linus Torvalds
Cc: Maria Dimakopoulou
Cc: Mark Davies
Cc: Paul Mackerras
Cc: Stephane Eranian
Cc: Yan, Zheng
Link: http://lkml.kernel.org/r/1405365957-20202-1-git-send-email-kan.liang@intel.com
Signed-off-by: Ingo Molnar
Cc: Dongsu Park
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 9772b54c55266ce80c639a80aa68eeb908f8ecf5 ]
To accomodate for enough headroom for tunnels, use MAX_HEADER instead
of LL_MAX_HEADER. Robert reported that he has hit after roughly 40hrs
of trinity an skb_under_panic() via SCTP output path (see reference).
I couldn't reproduce it from here, but not using MAX_HEADER as elsewhere
in other protocols might be one possible cause for this.In any case, it looks like accounting on chunks themself seems to look
good as the skb already passed the SCTP output path and did not hit
any skb_over_panic(). Given tunneling was enabled in his .config, the
headroom would have been expanded by MAX_HEADER in this case.Reported-by: Robert Święcki
Reference: https://lkml.org/lkml/2014/12/1/507
Fixes: 594ccc14dfe4d ("[SCTP] Replace incorrect use of dev_alloc_skb with alloc_skb in sctp_packet_transmit().")
Signed-off-by: Daniel Borkmann
Acked-by: Vlad Yasevich
Acked-by: Neil Horman
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 5f478b41033606d325e420df693162e2524c2b94 ]
mvneta_tx() dereferences skb to get skb->len too late,
as hardware might have completed the transmit and TX completion
could have freed the skb from another cpu.Fixes: 71f6d1b31fb1 ("net: mvneta: replace Tx timer with a real interrupt")
Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit aebea2ba0f7495e1a1c9ea5e753d146cb2f6b845 ]
The mvneta driver sets the amount of Tx coalesce packets to 16 by
default. Normally that does not cause any trouble since the driver
uses a much larger Tx ring size (532 packets). But some sockets
might run with very small buffers, much smaller than the equivalent
of 16 packets. This is what ping is doing for example, by setting
SNDBUF to 324 bytes rounded up to 2kB by the kernel.The problem is that there is no documented method to force a specific
packet to emit an interrupt (eg: the last of the ring) nor is it
possible to make the NIC emit an interrupt after a given delay.In this case, it causes trouble, because when ping sends packets over
its raw socket, the few first packets leave the system, and the first
15 packets will be emitted without an IRQ being generated, so without
the skbs being freed. And since the socket's buffer is small, there's
no way to reach that amount of packets, and the ping ends up with
"send: no buffer available" after sending 6 packets. Running with 3
instances of ping in parallel is enough to hide the problem, because
with 6 packets per instance, that's 18 packets total, which is enough
to grant a Tx interrupt before all are sent.The original driver in the LSP kernel worked around this design flaw
by using a software timer to clean up the Tx descriptors. This timer
was slow and caused terrible network performance on some Tx-bound
workloads (such as routing) but was enough to make tools like ping
work correctly.Instead here, we simply set the packet counts before interrupt to 1.
This ensures that each packet sent will produce an interrupt. NAPI
takes care of coalescing interrupts since the interrupt is disabled
once generated.No measurable performance impact nor CPU usage were observed on small
nor large packets, including when saturating the link on Tx, and this
fixes tools like ping which rely on too small a send buffer. If one
wants to increase this value for certain workloads where it is safe
to do so, "ethtool -C $dev tx-frames" will override this default
setting.This fix needs to be applied to stable kernels starting with 3.10.
Tested-By: Maggie Mae Roxas
Signed-off-by: Willy Tarreau
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 6fb2a756739aa507c1fd5b8126f0bfc2f070dc46 ]
Set the inner mac header to point to the GRE payload when
doing GRO. This is needed if we proceed to send the packet
through GRE GSO which now uses the inner mac header instead
of inner network header to determine the length of encapsulation
headers.Fixes: 14051f0452a2 ("gre: Use inner mac length when computing tunnel length")
Reported-by: Wolfgang Walter
Signed-off-by: Tom Herbert
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit e0ebde0e131b529fd721b24f62872def5ec3718c ]
rtnl_link_get_net() holds a reference on the 'struct net', we need to release
it in case of error.CC: Eric W. Biederman
Fixes: b51642f6d77b ("net: Enable a userns root rtnl calls that are safe for unprivilged users")
Signed-off-by: Nicolas Dichtel
Reviewed-by: "Eric W. Biederman"
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 2d5c57d7fbfaa642fb7f0673df24f32b83d9066c ]
Some VF drivers use the upper byte of "param1" (the qp count field)
in mlx4_qp_reserve_range() to pass flags which are used to optimize
the range allocation.Under the current code, if any of these flags are set, the 32-bit
count field yields a count greater than 2^24, which is out of range,
and this VF fails.As these flags represent a "best-effort" allocation hint anyway, they may
safely be ignored. Therefore, the PF driver may simply mask out the bits.Fixes: c82e9aa0a8 "mlx4_core: resource tracking for HCA resources used by guests"
Signed-off-by: Jack Morgenstein
Signed-off-by: Or Gerlitz
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit a620a6bc1c94c22d6c312892be1e0ae171523125 ]
If TX channels are set to 4 and RX channels are set to less than 4,
using ethtool -L, the driver will try to initialize more RX channels
than it has allocated, causing an oops.This fix only initializes the RX ring if it has been allocated.
Signed-off-by: Thadeu Lima de Souza Cascardo
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 00c83b01d58068dfeb2e1351cca6fccf2a83fa8f ]
Currently, when trying to reuse a socket, vxlan_sock_add will grab
vn->sock_lock, locate a reusable socket, inc refcount and release
vn->sock_lock.But vxlan_sock_release() will first decrement refcount, and then grab
that lock. refcnt operations are atomic but as currently we have
deferred works which hold vs->refcnt each, this might happen, leading to
a use after free (specially after vxlan_igmp_leave):CPU 1 CPU 2
deferred work vxlan_sock_add
... ...
spin_lock(&vn->sock_lock)
vs = vxlan_find_sock();
vxlan_sock_release
dec vs->refcnt, reaches 0
spin_lock(&vn->sock_lock)
vxlan_sock_hold(vs), refcnt=1
spin_unlock(&vn->sock_lock)
hlist_del_rcu(&vs->hlist);
vxlan_notify_del_rx_port(vs)
spin_unlock(&vn->sock_lock)So when we look for a reusable socket, we check if it wasn't freed
already before reusing it.Signed-off-by: Marcelo Ricardo Leitner
Fixes: 7c47cedf43a8b3 ("vxlan: move IGMP join/leave to work queue")
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit be6572fdb1bfbe23b2624d477de50af50b02f5d6 ]
When using GRE redirection in WCCP, it sets the wrong skb->protocol,
that is, ETH_P_IP instead of ETH_P_IPV6 for the encapuslated traffic.Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
Cc: Dmitry Kozlov
Signed-off-by: Yuri Chislov
Tested-by: Yuri Chislov
Signed-off-by: Daniel Borkmann
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 20ea60ca9952bd19d4b0d74719daba305aef5178 ]
Now the vti_link_ops do not point the .dellink, for fb tunnel device
(ip_vti0), the net_device will be removed as the default .dellink is
unregister_netdevice_queue,but the tunnel still in the tunnel list,
then if we add a new vti tunnel, in ip_tunnel_find():hlist_for_each_entry_rcu(t, head, hash_node) {
if (local == t->parms.iph.saddr &&
remote == t->parms.iph.daddr &&
link == t->parms.link &&
==> type == t->dev->type &&
ip_tunnel_key_match(&t->parms, flags, key))
break;
}the panic will happen, cause dev of ip_tunnel *t is null:
[ 3835.072977] IP: [] ip_tunnel_find+0x9d/0xc0 [ip_tunnel]
[ 3835.073008] PGD b2c21067 PUD b7277067 PMD 0
[ 3835.073008] Oops: 0000 [#1] SMP
.....
[ 3835.073008] Stack:
[ 3835.073008] ffff8800b72d77f0 ffffffffa0411924 ffff8800bb956000 ffff8800b72d78e0
[ 3835.073008] ffff8800b72d78a0 0000000000000000 ffffffffa040d100 ffff8800b72d7858
[ 3835.073008] ffffffffa040b2e3 0000000000000000 0000000000000000 0000000000000000
[ 3835.073008] Call Trace:
[ 3835.073008] [] ip_tunnel_newlink+0x64/0x160 [ip_tunnel]
[ 3835.073008] [] vti_newlink+0x43/0x70 [ip_vti]
[ 3835.073008] [] rtnl_newlink+0x4fa/0x5f0
[ 3835.073008] [] ? nla_strlcpy+0x5b/0x70
[ 3835.073008] [] ? rtnl_link_ops_get+0x40/0x60
[ 3835.073008] [] ? rtnl_newlink+0x13f/0x5f0
[ 3835.073008] [] rtnetlink_rcv_msg+0xa4/0x270
[ 3835.073008] [] ? sock_has_perm+0x75/0x90
[ 3835.073008] [] ? rtnetlink_rcv+0x30/0x30
[ 3835.073008] [] netlink_rcv_skb+0xa9/0xc0
[ 3835.073008] [] rtnetlink_rcv+0x28/0x30
....modprobe ip_vti
ip link del ip_vti0 type vti
ip link add ip_vti0 type vti
rmmod ip_vtido that one or more times, kernel will panic.
fix it by assigning ip_tunnel_dellink to vti_link_ops' dellink, in
which we skip the unregister of fb tunnel device. do the same on ip6_vti.Signed-off-by: Xin Long
Signed-off-by: Cong Wang
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit aad0b624129709c94c2e19e583b6053520353fa8 upstream.
irq_of_parse_and_map() returns 0 on error (the result is unsigned int),
so testing for negative result never works.Signed-off-by: Dmitry Torokhov
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman -
commit 2b21ef0aae65f22f5ba86b13c4588f6f0c2dbefb upstream.
Just like 0x1600 which got blacklisted by 66a7cbc303f4 ("ahci: disable
MSI instead of NCQ on Samsung pci-e SSDs on macbooks"), 0xa800 chokes
on NCQ commands if MSI is enabled. Disable MSI.Signed-off-by: Tejun Heo
Reported-by: Dominik Mierzejewski
Link: https://bugzilla.kernel.org/show_bug.cgi?id=89171
Signed-off-by: Greg Kroah-Hartman -
commit 249cd0a187ed4ef1d0af7f74362cc2791ec5581b upstream.
This patch adds DeviceIDs for Sunrise Point-LP.
Signed-off-by: Devin Ryles
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman -
commit 8e71a322fdb127814bcba423a512914ca5bc6cf5 upstream.
If a device is halted and reuturns a STALL, then the halted endpoint
needs to be cleared both on the host and device side. The host
side halt is cleared by issueing a xhci reset endpoint command. The device side
is cleared with a ClearFeature(ENDPOINT_HALT) request, which should
be issued by the device driver if a URB reruen -EPIPE.Previously we cleared the host side halt after the device side was cleared.
To make sure the host side halt is cleared in time we want to issue the
reset endpoint command immedialtely when a STALL status is encountered.Otherwise we end up not following the specs and not returning -EPIPE
several times in a row when trying to transfer data to a halted endpoint.Fixes: bcef3fd (USB: xhci: Handle errors that cause endpoint halts.)
Tested-by: Felipe Balbi
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman -
commit b31eb901c4e5eeef4c83c43dfbc7fe0d4348cb21 upstream.
Setting a non-settable selection target caused BUG() to be called. The check
for valid selections only takes the selection target into account, but does
not tell whether it may be set, or only get. Fix the issue by simply
returning an error to the user.Signed-off-by: Sakari Ailus
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit e2e68ae688b0a3766cd75aedf4ed4e39be402009 upstream.
commit e6023367d779 'x86, kaslr: Prevent .bss from overlaping initrd'
broke the cross compile of x86. It added a objdump invocation, which
invokes the host native objdump and ignores an active cross tool
chain.Use $(OBJDUMP) instead which takes the CROSS_COMPILE prefix into
account.[ tglx: Massage changelog and use $(OBJDUMP) ]
Fixes: e6023367d779 'x86, kaslr: Prevent .bss from overlaping initrd'
Signed-off-by: Chris Clayton
Acked-by: Kees Cook
Acked-by: Borislav Petkov
Cc: Junjie Mao
Cc: Ingo Molnar
Cc: H. Peter Anvin
Link: http://lkml.kernel.org/r/54705C8E.1080400@googlemail.com
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit b0616c5306b342ceca07044dbc4f917d95c4f825 upstream.
Otherwise we'll have backtraces in assert_panel_unlocked because the
BIOS locks the register. In the reporter's case this regression was
introduced incommit c31407a3672aaebb4acddf90944a114fa5c8af7b
Author: Chris Wilson
Date: Thu Oct 18 21:07:01 2012 +0100drm/i915: Add no-lvds quirk for Supermicro X7SPA-H
Reported-by: Alexey Orishko
Cc: Alexey Orishko
Cc: Chris Wilson
Cc: Francois Tigeot
Signed-off-by: Daniel Vetter
Tested-by: Alexey Orishko
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit b68362278af94e1171f5be9d4e44988601fb0439 upstream.
Apparently PCH fifo underruns are tricky, we have plenty reports that
we see the occasional underrun (especially at boot-up).So for a change let's see what happens when we don't re-enable pch
fifo underrun reporting when the pipe is disabled. This means that the
kernel can't catch pch fifo underruns when they happen (except when
all pipes are on on the pch). But we'll still catch underruns when
disabling the pipe again. So not a terrible reduction in test
coverage.Since the DRM_ERROR is new and hence a regression plan B would be to
revert it back to a debug output. Which would be a lot worse than this
hack for underrun test coverage in the wild. See the referenced
discussions for more.References: http://mid.gmane.org/CA+gsUGRfGe3t4NcjdeA=qXysrhLY3r4CEu7z4bjTwxi1uOfy+g@mail.gmail.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85898
References: https://bugs.freedesktop.org/show_bug.cgi?id=85898
References: https://bugs.freedesktop.org/show_bug.cgi?id=86233
References: https://bugs.freedesktop.org/show_bug.cgi?id=86478
Signed-off-by: Daniel Vetter
Tested-by: lu hua
Reviewed-by: Paulo Zanoni
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit f5475cc43c899e33098d4db44b7c5e710f16589d upstream.
I was unable too boot 3.18.0-rc6 because of the following kernel
panic in drm_calc_vbltimestamp_from_scanoutpos():[drm] Initialized drm 1.1.0 20060810
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080).
[drm] register mmio base: 0xC8400000
[drm] register mmio size: 65536
radeon 0000:0b:01.0: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (16M used)
radeon 0000:0b:01.0: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF
[drm] Detected VRAM RAM=128M, BAR=128M
[drm] RAM width 16bits DDR
[TTM] Zone kernel: Available graphics memory: 3829346 kiB
[TTM] Zone dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
[drm] radeon: 16M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] PCI GART of 512M enabled (table at 0x0000000037880000).
radeon 0000:0b:01.0: WB disabled
radeon 0000:0b:01.0: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0xffff8800bbbfa000
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
[drm] Loading R100 Microcode
radeon 0000:0b:01.0: Direct firmware load for radeon/R100_cp.bin failed with error -2
radeon_cp: Failed to load firmware "radeon/R100_cp.bin"
[drm:r100_cp_init] *ERROR* Failed to load firmware!
radeon 0000:0b:01.0: failed initializing CP (-2).
radeon 0000:0b:01.0: Disabling GPU acceleration
[drm] radeon: cp finalized
BUG: unable to handle kernel NULL pointer dereference at 000000000000025c
IP: [] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
PGD 0
Oops: 0000 [#1] SMP
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc6-4-default #2649
Hardware name: Supermicro X7DB8/X7DB8, BIOS 6.00 07/26/2006
task: ffff880234da2010 ti: ffff880234da4000 task.ti: ffff880234da4000
RIP: 0010:[] [] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
RSP: 0000:ffff880234da7918 EFLAGS: 00010086
RAX: ffffffff81557890 RBX: 0000000000000000 RCX: ffff880234da7a48
RDX: ffff880234da79f4 RSI: 0000000000000000 RDI: ffff880232e15000
RBP: ffff880234da79b8 R08: 0000000000000000 R09: 0000000000000000
R10: 000000000000000a R11: 0000000000000001 R12: ffff880232dda1c0
R13: ffff880232e1518c R14: 0000000000000292 R15: ffff880232e15000
FS: 0000000000000000(0000) GS:ffff88023fc40000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000000025c CR3: 0000000002014000 CR4: 00000000000007e0
Stack:
ffff880234da79d8 0000000000000286 ffff880232dcbc00 0000000000002480
ffff880234da7958 0000000000000296 ffff880234da7998 ffffffff8151b51d
ffff880234da7a48 0000000032dcbeb0 ffff880232dcbc00 ffff880232dcbc58
Call Trace:
[] ? drm_vma_offset_remove+0x1d/0x110
[] radeon_get_vblank_timestamp_kms+0x38/0x60
[] ? ttm_bo_release_list+0xba/0x180
[] drm_get_last_vbltimestamp+0x41/0x70
[] vblank_disable_and_save+0x73/0x1d0
[] ? try_to_del_timer_sync+0x4f/0x70
[] drm_vblank_cleanup+0x65/0xa0
[] radeon_irq_kms_fini+0x1a/0x70
[] r100_init+0x26e/0x410
[] radeon_device_init+0x7ae/0xb50
[] radeon_driver_load_kms+0x8f/0x210
[] drm_dev_register+0xb5/0x110
[] drm_get_pci_dev+0x8f/0x200
[] radeon_pci_probe+0xad/0xe0
[] local_pci_probe+0x45/0xa0
[] pci_device_probe+0xd1/0x130
[] driver_probe_device+0x12d/0x3e0
[] __driver_attach+0x9b/0xa0
[] ? __device_attach+0x40/0x40
[] bus_for_each_dev+0x63/0xa0
[] driver_attach+0x1e/0x20
[] bus_add_driver+0x180/0x240
[] driver_register+0x64/0xf0
[] __pci_register_driver+0x4c/0x50
[] drm_pci_init+0xf5/0x120
[] ? ttm_init+0x6a/0x6a
[] radeon_init+0x97/0xb5
[] do_one_initcall+0xbc/0x1f0
[] ? __wake_up+0x48/0x60
[] kernel_init_freeable+0x18a/0x215
[] ? initcall_blacklist+0xc0/0xc0
[] ? rest_init+0x80/0x80
[] kernel_init+0xe/0xf0
[] ret_from_fork+0x7c/0xb0
[] ? rest_init+0x80/0x80
Code: 45 ac 0f 88 a8 01 00 00 3b b7 d0 01 00 00 49 89 ff 0f 83 99 01 00 00 48 8b 47 20 48 8b 80 88 00 00 00 48 85 c0 0f 84 cd 01 00 00 8b b1 5c 02 00 00 41 8b 89 58 02 00 00 89 75 98 41 8b b1 60
RIP [] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
RSP
CR2: 000000000000025c
---[ end trace ad2c0aadf48e2032 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009It has helped me to add a NULL pointer check that was suggested at
http://lists.freedesktop.org/archives/dri-devel/2014-October/070663.htmlI am not familiar with the code. But the change looks sane
and we need something fast at this stage of 3.18 development.Suggested-by: Helge Deller
Signed-off-by: Petr Mladek
Tested-by: Petr Mladek
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 9ea359f7314132cbcb5a502d2d8ef095be1f45e4 upstream.
According to I2C specification the NACK should be handled as follows:
"When SDA remains HIGH during this ninth clock pulse, this is defined as the Not
Acknowledge signal. The master can then generate either a STOP condition to
abort the transfer, or a repeated START condition to start a new transfer."
[I2C spec Rev. 6, 3.1.6: http://www.nxp.com/documents/user_manual/UM10204.pdf]Currently the Davinci i2c driver interrupts the transfer on receipt of a
NACK but fails to send a STOP in some situations and so makes the bus
stuck until next I2C IP reset (idle/enable).For example, the issue will happen during SMBus read transfer which
consists from two i2c messages write command/address and read data:S Slave Address Wr A Command Code A Sr Slave Address Rd A D1..Dn A P
The I2C client device will send NACK if it can't recognize "Command Code"
and it's expected from I2C master to generate STP in this case.
But now, Davinci i2C driver will just exit with -EREMOTEIO and STP will
not be generated.Hence, fix it by generating Stop condition (STP) always when NACK is received.
This patch fixes Davinci I2C in the same way it was done for OMAP I2C
commit cda2109a26eb ("i2c: omap: query STP always when NACK is received").Reviewed-by: Uwe Kleine-König
Reported-by: Hein Tibosch
Signed-off-by: Grygorii Strashko
Signed-off-by: Wolfram Sang
Signed-off-by: Greg Kroah-Hartman -
commit ccfc866356674cb3a61829d239c685af6e85f197 upstream.
commit 6d9939f651419a63e091105663821f9c7d3fec37 (i2c: omap: split out [XR]DR
and [XR]RDY) changed the way how errata i207 (I2C: RDR Flag May Be Incorrectly
Set) get handled. 6d9939f6514 code doesn't correspond to workaround provided by
errata.According to errata ISR must filter out spurious RDR before data read not after.
ISR must read RXSTAT to get number of bytes available to read. Because RDR
could be set while there could no data in the receive FIFO.Restored pre 6d9939f6514 way of handling errata.
Found by code review. Real impact haven't seen.
Tested on Beagleboard XM C.Signed-off-by: Alexander Kochetkov
Fixes: 6d9939f651419a63e09110 i2c: omap: split out [XR]DR and [XR]RDY
Tested-by: Felipe Balbi
Reviewed-by: Felipe Balbi
Signed-off-by: Wolfram Sang
Signed-off-by: Greg Kroah-Hartman -
commit 27caca9d2e01c92b26d0690f065aad093fea01c7 upstream.
commit 1d7afc95946487945cc7f5019b41255b72224b70 (i2c: omap: ack IRQ in parts)
changed the interrupt handler to complete transfers without clearing
XRDY (AL case) and ARDY (NACK case) flags. XRDY or ARDY interrupts will be
fired again. As a result, ISR keep processing transfer after it was already
complete (from the driver code point of view).A didn't see real impacts of the 1d7afc9, but it is really bad idea to
have ISR running on user data after transfer was complete.It looks, what 1d7afc9 violate TI specs in what how AL and NACK should be
handled (see Note 1, sprugn4r, Figure 17-31 and Figure 17-32).According to specs (if I understood correctly), in case of NACK and AL driver
must reset NACK, AL, ARDY, RDR, and RRDY (Master Receive Mode), and
NACK, AL, ARDY, and XDR (Master Transmitter Mode).All that is done down the code under the if condition:
if (stat & (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) ...The patch restore pre 1d7afc9 logic of handling NACK and AL interrupts, so
no interrupts is fired after ISR informs the rest of driver what transfer
complete.Note: instead of removing break under NACK case, we could just replace 'break'
with 'continue' and allow NACK transfer to finish using ARDY event. I found
that NACK and ARDY bits usually set together. That case confirm TI wiki:
http://processors.wiki.ti.com/index.php/I2C_Tips#Detecting_and_handling_NACKIn order if someone interested in the event traces for NACK and AL cases,
I sent them to mailing list.Tested on Beagleboard XM C.
Signed-off-by: Alexander Kochetkov
Fixes: 1d7afc9 i2c: omap: ack IRQ in parts
Acked-by: Felipe Balbi
Tested-by: Aaro Koskinen
Signed-off-by: Wolfram Sang
Signed-off-by: Greg Kroah-Hartman -
commit 8d609725d4357f499e2103e46011308b32f53513 upstream.
These BUGs can be erroneously triggered by frags which refer to
tail pages within a compound page. The data in these pages may
overrun the hardware page while still being contained within the
compound page, but since compound_order() evaluates to 0 for tail
pages the assertion fails. The code already iterates through
subsequent pages correctly in this scenario, so the BUGs are
unnecessary and can be removed.Fixes: f36c374782e4 ("xen/netfront: handle compound page fragments on transmit")
Signed-off-by: Seth Forshee
Reviewed-by: David Vrabel
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit c4ea95d7cd08d9ffd7fa75e6c5e0332d596dd11e upstream.
Andrew Morton noticed that the error return from anon_vma_clone() was
being dropped and replaced with -ENOMEM (which is not itself a bug
because the only error return value from anon_vma_clone() is -ENOMEM).I did an audit of callers of anon_vma_clone() and discovered an actual
bug where the error return was being lost. In __split_vma(), between
Linux 3.11 and 3.12 the code was changed so the err variable is used
before the call to anon_vma_clone() and the default initial value of
-ENOMEM is overwritten. So a failure of anon_vma_clone() will return
success since err at this point is now zero.Below is a patch which fixes this bug and also propagates the error
return value from anon_vma_clone() in all cases.Fixes: ef0855d334e1 ("mm: mempolicy: turn vma_set_policy() into vma_dup_policy()")
Signed-off-by: Daniel Forrest
Reviewed-by: Michal Hocko
Cc: Konstantin Khlebnikov
Cc: Andrea Arcangeli
Cc: Rik van Riel
Cc: Tim Hartrick
Cc: Hugh Dickins
Cc: Michel Lespinasse
Cc: Vlastimil Babka
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 2022b4d18a491a578218ce7a4eca8666db895a73 upstream.
I've been seeing swapoff hangs in recent testing: it's cycling around
trying unsuccessfully to find an mm for some remaining pages of swap.I have been exercising swap and page migration more heavily recently,
and now notice a long-standing error in copy_one_pte(): it's trying to
add dst_mm to swapoff's mmlist when it finds a swap entry, but is doing
so even when it's a migration entry or an hwpoison entry.Which wouldn't matter much, except it adds dst_mm next to src_mm,
assuming src_mm is already on the mmlist: which may not be so. Then if
pages are later swapped out from dst_mm, swapoff won't be able to find
where to replace them.There's already a !non_swap_entry() test for stats: move that up before
the swap_duplicate() and the addition to mmlist.Signed-off-by: Hugh Dickins
Cc: Kelley Nielsen
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 91b57191cfd152c02ded0745250167d0263084f8 upstream.
In some android devices, there will be a "divide by zero" exception.
vmpr->scanned could be zero before spin_lock(&vmpr->sr_lock).Addresses https://bugzilla.kernel.org/show_bug.cgi?id=88051
[akpm@linux-foundation.org: neaten]
Reported-by: ji_ang
Cc: Anton Vorontsov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit fb993fa1a2f669215fa03a09eed7848f2663e336 upstream.
If a frontswap dup-store failed, it should invalidate the expired page
in the backend, or it could trigger some data corruption issue.
Such as:
1. use zswap as the frontswap backend with writeback feature
2. store a swap page(version_1) to entry A, success
3. dup-store a newer page(version_2) to the same entry A, fail
4. use __swap_writepage() write version_2 page to swapfile, success
5. zswap do shrink, writeback version_1 page to swapfile
6. version_2 page is overwrited by version_1, data corrupt.This patch fixes this issue by invalidating expired data immediately
when meet a dup-store failure.Signed-off-by: Weijie Yang
Cc: Konrad Rzeszutek Wilk
Cc: Seth Jennings
Cc: Dan Streetman
Cc: Minchan Kim
Cc: Bob Liu
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
07 Dec, 2014
5 commits
-
commit 92a56555bd576c61b27a5cab9f38a33a1e9a1df5 upstream.
If a SIGKILL is sent to a task waiting in __nfs_iocounter_wait,
it will busy-wait or soft lockup in its while loop.
nfs_wait_bit_killable won't sleep, and the loop won't exit on
the error return.Stop the busy-wait by breaking out of the loop when
nfs_wait_bit_killable returns an error.Signed-off-by: David Jeffery
Signed-off-by: Trond Myklebust
[ kamal: backport to 3.13-stable: context ]
Cc: Moritz Mühlenhoff
Signed-off-by: Kamal Mostafa
Signed-off-by: Greg Kroah-Hartman -
commit c1118b3602c2329671ad5ec8bdf8e374323d6343 upstream.
On x86_64, kernel text mappings are mapped read-only with CONFIG_DEBUG_RODATA.
In that case, KVM will fail to patch VMCALL instructions to VMMCALL
as required on AMD processors.The failure mode is currently a divide-by-zero exception, which obviously
is a KVM bug that has to be fixed. However, picking the right instruction
between VMCALL and VMMCALL will be faster and will help if you cannot upgrade
the hypervisor.Reported-by: Chris Webb
Tested-by: Chris Webb
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x86@kernel.org
Acked-by: Borislav Petkov
Signed-off-by: Paolo Bonzini
Signed-off-by: Chris J Arges
Signed-off-by: Greg Kroah-Hartman -
commit b6ed5498601df40489606dbc14a9c7011c16630b upstream.
batman tries to search dev->iflink to check if it's a batman interface,
but ->iflink could be 0, which is not a valid ifindex. It should just
avoid iflink == 0 case.Reported-by: Jet Chen
Tested-by: Jet Chen
Cc: David S. Miller
Cc: Steffen Klassert
Cc: Antonio Quartulli
Cc: Marek Lindner
Signed-off-by: Cong Wang
Signed-off-by: Cong Wang
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 360743814c4082515581aa23ab1d8e699e1fbe88 upstream.
Instead of the arch specific quirk which we are deprecating
and that drivers don't understand.Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman
