| Age | Commit message (Collapse) | Author |
|---|
|
commit 91a13c281d7d4648c0b32dede11a0144c4e7984c upstream.
Patch to fix the error message "directives may not be used inside a macro
argument" which appears when the kernel is compiled for the cris architecture.
Signed-off-by: Claudio Scordino <claudio@evidence.eu.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 161f14191dc166c4e3f37f68af1bc199c6868b7d upstream.
Since 43cc71eed1250755986da4c0f9898f9a635cb3bf (platform: prefix MODALIAS
with "platform:"), the platform modalias is prefixed with "platform:".
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Pratyush Anand <pratyush.anand@st.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Backported from commit b95d68b8179764e29558b75cec35ef4a6a98925b.
memset(eld) clears eld->proc_entry which will leak the struct
snd_info_entry when unloading module.
Fix it by
- memset only the fields before eld->eld_buffer
- set eld->eld_valid to true _after_ all eld fields have been filled
Cc: Pierre-louis Bossart <pierre-louis.bossart@intel.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 1788ea6e3b2a58cf4fb00206e362d9caff8d86a7 upstream.
commit d953126 changed how nfs_atomic_lookup handles an -EISDIR return
from an OPEN call. Prior to that patch, that caused the client to fall
back to doing a normal lookup. When that patch went in, the code began
returning that error to userspace. The d_revalidate codepath however
never had the corresponding change, so it was still possible to end up
with a NULL ctx->state pointer after that.
That patch caused a regression. When we attempt to open a directory that
does not have a cached dentry, that open now errors out with EISDIR. If
you attempt the same open with a cached dentry, it will succeed.
Fix this by reverting the change in nfs_atomic_lookup and allowing
attempts to open directories to fall back to a normal lookup
Also, add a NFSv4-specific f_ops->open routine that just returns
-ENOTDIR. This should never be called if things are working properly,
but if it ever is, then the dprintk may help in debugging.
To facilitate this, a new file_operations field is also added to the
nfs_rpc_ops struct.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 0c73c08ec73dbe080b9ec56696ee21d32754d918 upstream.
For /dev/console case, we do not kill all ldisc users. It's due to
redirected_tty_write test in __tty_hangup. In that case there still
might be a process waiting e.g. in n_tty_read for input.
We wait for such processes to disappear. The problem is that we use a
timeout. After this timeout, we continue closing the ldisc and start
freeing tty resources. It obviously leads to crashes when the other
process is woken.
So to fix this, we wait infinitely before reiniting the ldisc. (The
tiocsetd remains untouched -- times out after 5s.)
This is nicely reproducible with this run from shell:
exec 0<>/dev/console 1<>/dev/console 2<>/dev/console
and stopping a getty like:
systemctl stop serial-getty@ttyS0.service
The crash proper may be produced only under load or with constified
timing the same as for 92f6fa09b.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Dave Young <hidave.darkstar@gmail.com>
Cc: Dave Jones <davej@redhat.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Dmitriy Matrosov <sgf.dma@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 300420722e0734a4254f3b634e0f82664495d210 upstream.
It is the only place where reinit is called from. And we really need
to wait for the old ldisc to go once. Actually this is the place where
the waiting originally was (before removed and re-added later).
This will make the fix in the following patch easier to implement.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Dave Young <hidave.darkstar@gmail.com>
Cc: Dave Jones <davej@redhat.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Dmitriy Matrosov <sgf.dma@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit df92d0561de364de53c42abc5d43e04ab6f326a5 upstream.
To fix a nasty bug in ldisc hup vs. reinit we need to wait infinitely
long for ldisc to be gone. So here we add a parameter to
tty_ldisc_wait_idle to allow that.
This is only a preparation for the real fix which is done in the
following patches.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Dave Young <hidave.darkstar@gmail.com>
Cc: Dave Jones <davej@redhat.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Dmitriy Matrosov <sgf.dma@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit c2a3e84f950e7ddba1f3914b005861d46ae60359 upstream.
Reading from the DCC grabs a character from the buffer and
clears the status bit. Since this is a context-changing
operation, instructions following the character read that rely on
the status bit being accurate need to be synchronized with an
ISB.
In this case, the status bit check needs to execute after the
character read otherwise we run the risk of reading the character
and checking the status bit before the read can clear the status
bit in the first place. When this happens, the user will see the
same character they typed twice, instead of once.
Add an ISB after the read and the write, so that the status check
is synchronized with the read/write operations.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 8249f743f732ccbc3056428945ab1d9bd36d46bf upstream.
ML7831 is companion chip for Intel Atom E6xx series.
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.lapis-semi.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 90f04c2926cfb5bf74533b0a7766bc896f6a0c0e upstream.
Changing UART mode PIO->DMA->PIO->DMA like below, pch_uart driver can't get
DMA channel resource.
setserial /dev/ttyPCH0 ^low_latency
setserial /dev/ttyPCH0 low_latency
CAUSE:
Changing mode using setserial command, ".startup" function which gets DMA
channel is called before ".verify_port" function which sets
dma-flag(use_dma/use_dma_flag) as 1.
PIO->DMA
.startup: Since dma-flag is 0, DMA channel is not requested.
.verify_port: dma-flag is set as 1.
.shutdown: N/A
DMA->PIO
.startup: Since dma-flag is 1, DMA channel is requested.
.verify_port: dma-flag is set as 0.
.shutdown: Since dma-flag is 0, DMA channel is not released.
This means DMA channel resource leak occurs.
Next time, this driver can't get DMA channel resource forever.
MODIFICATION:
Currently, when release DMA channel resource, this driver checks dma-flag.
However, this specification occurs the above issue.
This driver must check whether dma_request_channel is executed or not.
The values are saved in private data variable "chan_tx/chan_tx".
These variables mean if the value is NULL, DMA channel is not requested,
if not NULL, DMA channel is requested.
This patch fixes the issue.
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit a1d7cfe29f13cf45f8094929864b9c66bf0cd91b upstream.
Using hardware flow control,
currently, register of the control-bit(AFE) is not set.
This patch fixes the issue.
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.lapis-semi.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 2a9887919457c6e1bd482e8448223be59d19010a upstream.
ISSUE:
Using ML7831, MAC address writing doesn't work well.
CAUSE:
ML7831 and EG20T have the same register map for MAC address access.
However, this driver processes the writing the same as ML7223.
This is not true.
This driver must process the writing the same as EG20T.
This patch fixes the issue.
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Cc: Masayuki Ohtak <masa-korg@dsn.okisemi.com>
Cc: Alexander Stein <alexander.stein@systec-electronic.com>
Cc: Denis Turischev <denis@compulab.co.il>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 584ad00ce4bfe594e4c4a89944b3c635187a1ca1 upstream.
ML7831 is companion chip for Intel Atom E6xx series.
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.lapis-semi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit af8db1508f2c9f3b6e633e2d2d906c6557c617f9 upstream.
There may be an issue when the user issue "reboot/shutdown" command, then
the device has shut down its hardware, after that, this runtime-pm featured
device's driver will probably be scheduled to do its suspend routine,
and at its suspend routine, it may access hardware, but the device has
already shutdown physically, then the system hang may be occurred.
I ran out this issue using an auto-suspend supported USB devices, like
3G modem, keyboard. The usb runtime suspend routine may be scheduled
after the usb controller has been shut down, and the usb runtime suspend
routine will try to suspend its roothub(controller), it will access
register, then the system hang occurs as the controller is shutdown.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Acked-by: Ming Lei <tom.leiming@gmail.com>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 731abb9cb27aef6013ce60808a04e04a545f3f4e upstream.
Commit 1c5cae815d removed an explicit call to dev_alloc_name in ip6_tnl_create
because register_netdevice will now create a valid name. This works for the
net_device itself.
However the tunnel keeps a copy of the name in the parms structure for the
ip6_tnl associated with the tunnel. parms.name is set by copying the net_device
name in ip6_tnl_dev_init_gen. That function is called from ip6_tnl_dev_init in
ip6_tnl_create, but it is done before register_netdevice is called so the name
is set to a bogus value in the parms.name structure.
This shows up if you do a simple tunnel add, followed by a tunnel show:
[root@localhost ~]# ip -6 tunnel add remote fec0::100 local fec0::200
[root@localhost ~]# ip -6 tunnel show
ip6tnl0: ipv6/ipv6 remote :: local :: encaplimit 0 hoplimit 0 tclass 0x00 flowlabel 0x00000 (flowinfo 0x00000000)
ip6tnl%d: ipv6/ipv6 remote fec0::100 local fec0::200 encaplimit 4 hoplimit 64 tclass 0x00 flowlabel 0x00000 (flowinfo 0x00000000)
[root@localhost ~]#
Fix this by moving the strcpy out of ip6_tnl_dev_init_gen, and calling it after
register_netdevice has successfully returned.
Signed-off-by: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 58ebacc66bd11be2327edcefc79de94bd6f5bb4a upstream.
Commit 4d9d88d1 by Scott James Remnant <keybuk@google.com> added
the .uevent() callback for the regulatory device used during
the platform device registration. The change was done to account
for queuing up udev change requests through udevadm triggers.
The change also meant that upon regulatory core exit we will now
send a uevent() but the uevent() callback, reg_device_uevent(),
also accessed last_request. Right before commiting device suicide
we free'd last_request but never set it to NULL so
platform_device_unregister() would lead to bogus kernel paging
request. Fix this and also simply supress uevents right before
we commit suicide as they are pointless.
This fix is required for kernels >= v2.6.39
$ git describe --contains 4d9d88d1
v2.6.39-rc1~468^2~25^2^2~21
The impact of not having this present is that a bogus paging
access may occur (only read) upon cfg80211 unload time. You
may also get this BUG complaint below. Although Johannes
could not reproduce the issue this fix is theoretically correct.
mac80211_hwsim: unregister radios
mac80211_hwsim: closing netlink
BUG: unable to handle kernel paging request at ffff88001a06b5ab
IP: [<ffffffffa030df9a>] reg_device_uevent+0x1a/0x50 [cfg80211]
PGD 1836063 PUD 183a063 PMD 1ffcb067 PTE 1a06b160
Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
CPU 0
Modules linked in: cfg80211(-) [last unloaded: mac80211]
Pid: 2279, comm: rmmod Tainted: G W 3.1.0-wl+ #663 Bochs Bochs
RIP: 0010:[<ffffffffa030df9a>] [<ffffffffa030df9a>] reg_device_uevent+0x1a/0x50 [cfg80211]
RSP: 0000:ffff88001c5f9d58 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff88001d2eda88 RCX: ffff88001c7468fc
RDX: ffff88001a06b5a0 RSI: ffff88001c7467b0 RDI: ffff88001c7467b0
RBP: ffff88001c5f9d58 R08: 000000000000ffff R09: 000000000000ffff
R10: 0000000000000000 R11: 0000000000000001 R12: ffff88001c7467b0
R13: ffff88001d2eda78 R14: ffffffff8164a840 R15: 0000000000000001
FS: 00007f8a91d8a6e0(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffff88001a06b5ab CR3: 000000001c62e000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process rmmod (pid: 2279, threadinfo ffff88001c5f8000, task ffff88000023c780)
Stack:
ffff88001c5f9d98 ffffffff812ff7e5 ffffffff8176ab3d ffff88001c7468c2
000000000000ffff ffff88001d2eda88 ffff88001c7467b0 ffff880000114820
ffff88001c5f9e38 ffffffff81241dc7 ffff88001c5f9db8 ffffffff81040189
Call Trace:
[<ffffffff812ff7e5>] dev_uevent+0xc5/0x170
[<ffffffff81241dc7>] kobject_uevent_env+0x1f7/0x490
[<ffffffff81040189>] ? sub_preempt_count+0x29/0x60
[<ffffffff814cab1a>] ? _raw_spin_unlock_irqrestore+0x4a/0x90
[<ffffffff81305307>] ? devres_release_all+0x27/0x60
[<ffffffff8124206b>] kobject_uevent+0xb/0x10
[<ffffffff812fee27>] device_del+0x157/0x1b0
[<ffffffff8130377d>] platform_device_del+0x1d/0x90
[<ffffffff81303b76>] platform_device_unregister+0x16/0x30
[<ffffffffa030fffd>] regulatory_exit+0x5d/0x180 [cfg80211]
[<ffffffffa032bec3>] cfg80211_exit+0x2b/0x45 [cfg80211]
[<ffffffff8109a84c>] sys_delete_module+0x16c/0x220
[<ffffffff8108a23e>] ? trace_hardirqs_on_caller+0x7e/0x120
[<ffffffff814cba02>] system_call_fastpath+0x16/0x1b
Code: <all your base are belong to me>
RIP [<ffffffffa030df9a>] reg_device_uevent+0x1a/0x50 [cfg80211]
RSP <ffff88001c5f9d58>
CR2: ffff88001a06b5ab
---[ end trace 147c5099a411e8c0 ]---
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Cc: Scott James Remnant <keybuk@google.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 6c7394197af90f6a332180e33f5d025d3037d883 upstream.
Since the NL80211_ATTR_HT_CAPABILITY attribute is
used as a struct, it needs a minimum, not maximum
length. Enforce that properly. Not doing so could
potentially lead to reading after the buffer.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 5b2bbf75a24d6b06afff6de0eb4819413fd81971 upstream.
ieee80211_probereq_get() can return NULL in
which case we should clean up & return NULL
in ieee80211_build_probe_req() as well.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit f8d1ccf15568268c76f913b45ecdd33134387f1a upstream.
When receiving failed PLCP frames is enabled, there
won't be a rate pointer when we add the radiotap
header and thus the kernel will crash. Fix this by
not assuming the rate pointer is always valid. It's
still always valid for frames that have good PLCP
though, and that is checked & enforced.
This was broken by my
commit fc88518916793af8ad6a02e05ff254d95c36d875
Author: Johannes Berg <johannes.berg@intel.com>
Date: Fri Jul 30 13:23:12 2010 +0200
mac80211: don't check rates on PLCP error frames
where I removed the check in this case but didn't
take into account that the rate info would be used.
Reported-by: Xiaokang Qin <xiaokang.qin@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit ed66ba472a742cd8df37d7072804b2111cdb1014 upstream.
The generic powersaving code that determines after reception of a frame
whether the device should go back to sleep or whether is could stay
awake was calling rt2x00lib_config directly from RX tasklet context.
On a number of the devices this call can actually sleep, due to having
to confirm that the sleeping commands have been executed successfully.
Fix this by moving the call to rt2x00lib_config to a workqueue call.
This fixes bug https://bugzilla.redhat.com/show_bug.cgi?id=731672
Tested-by: Tomas Trnka <tomastrnka@gmx.com>
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit fe09b32a4361bea44169b2063e8c867cabb6a8ba upstream.
If we hit the default case in the switch in if_spi_host_to_card() we'll leak
the memory we allocated for 'packet'. This patch resolves the leak by freeing
the allocated memory in that case.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 8428e84d42179c2a00f5f6450866e70d802d1d05 upstream.
Recent gcc versions generate unaligned accesses by default on ARMv6 and
later processors. This patch ensures that the SCTLR.A bit is always
cleared on such processors to avoid kernel traping before
alignment_init() is called.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: John Linn <John.Linn@xilinx.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 9e6dabeffd1d0ec2aa19aa076c4886067238d442 upstream.
CPUSTAT_RUNNING was implemented signifying that a vcpu is not stopped.
This is not, however, what the architecture says: RUNNING should be
set when the host is acting on the behalf of the guest operating
system.
CPUSTAT_RUNNING has been changed to be set in kvm_arch_vcpu_load()
and to be unset in kvm_arch_vcpu_put().
For signifying stopped state of a vcpu, a host-controlled bit has
been used and is set/unset basically on the reverse as the old
CPUSTAT_RUNNING bit (including pushing it down into stop handling
proper in handle_stop()).
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Carsten Otte <cotte@de.ibm.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 62dd28d0c659db29bdb89cfe9f0aefe42f0adfe9 upstream.
Hauppauge have released a new model rev, sub id 8940, this adds
support.
[stoth@kernellabs.com: I modified Tony's patch slightly in relation to the
card numbering in saa7164.h, appending rather than inserting the new card
- normal practise]
Signed-off-by: Tony Jago <tony@hammertelecom.com.au>
Signed-off-by: Steven Toth <stoth@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit cf16123c9c8e346ed1dd171295a678d77648d7f8 upstream.
Aacraid controller can hang on some nodes if kernel uses non-default
(powersave) ASPM policy. Controller hangs shortly after successful load and
hardware detection. Scsi error handler detects this hang and tries to restart
hardware but it does not help.
Initially it was noticed on RHEL6-based openVZ kernel after backporting
aacraid driver from mainline (RHEL6 kernel with original driver works well)
http://bugzilla.openvz.org/show_bug.cgi?id=2043
This issue happens because default ASPM policy was changed in Red Hat
kernels. Therefore guys from Red Hat have noticed this problem long time ago:
on Fedora 12
https://bugzilla.redhat.com/show_bug.cgi?id=540478
on Fedora 14
https://bugzilla.redhat.com/show_bug.cgi?id=679385
In RHEL6 kernel this issue was fixed, ASPM was disabled in aacraid driver. In
kernel changelog I've found that seems it was done by Matthew Garrett: -
[scsi] aacraid: Disable ASPM by default (Matthew Garrett) [599735]
However seems this patch was not submitted to mainline. I've reproduced this
issue on vanilla 3.1.0 kernel booted with "pcie_aspm.policy=powersave" option,
So I believe it makes sense to do it now.
Signed-off-by: Vasily Averin <vvs@sw.ru>
[mjg: Checking the Windows drivers indicates that they disable ASPM under all
circumstances, so:]
Acked-by: Matthew Garrett <mjg@redhat.com>
Acked-by: Achim Leubner <Achim_Leubner@pmc-sierra.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit e5a44df85e8d78e5c2d3d2e4f59b460905691e2f upstream.
The Windows driver .inf disables ASPM on hpsa devices. Do the same because the
selection of a non default ASPM policy can cause the device to hang.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Acked-by: Mike Miller <mike.miller@hp.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 4e6c82b3614a18740ef63109d58743a359266daf upstream.
On Mon, 2011-11-07 at 17:24 +1100, Stephen Rothwell wrote:
> Hi all,
>
> Starting some time last week I am getting the following during boot on
> our PPC970 blade:
>
> calling .ipr_init+0x0/0x68 @ 1
> ipr: IBM Power RAID SCSI Device Driver version: 2.5.2 (April 27, 2011)
> ipr 0000:01:01.0: Found IOA with IRQ: 26
> ipr 0000:01:01.0: Starting IOA initialization sequence.
> ipr 0000:01:01.0: Adapter firmware version: 06160039
> ipr 0000:01:01.0: IOA initialized.
> scsi0 : IBM 572E Storage Adapter
> ------------[ cut here ]------------
> WARNING: at drivers/scsi/scsi_lib.c:1704
> Modules linked in:
> NIP: c00000000053b3d4 LR: c00000000053e5b0 CTR: c000000000541d70
> REGS: c0000000783c2f60 TRAP: 0700 Not tainted (3.1.0-autokern1)
> MSR: 8000000000029032 <EE,ME,CE,IR,DR> CR: 24002024 XER: 20000002
> TASK = c0000000783b8000[1] 'swapper' THREAD: c0000000783c0000 CPU: 0
> GPR00: 0000000000000001 c0000000783c31e0 c000000000cf38b0 c00000000239a9d0
> GPR04: c000000000cbe8f8 0000000000000000 c0000000783c3040 0000000000000000
> GPR08: c000000075daf488 c000000078a3b7ff c000000000bcacc8 0000000000000000
> GPR12: 0000000044002028 c000000007ffb000 0000000002e40000 000000000099b800
> GPR16: 0000000000000000 c000000000bba5fc c000000000a61db8 0000000000000000
> GPR20: 0000000001b77200 0000000000000000 c000000078990000 0000000000000001
> GPR24: c000000002396828 0000000000000000 0000000000000000 c000000078a3b938
> GPR28: fffffffffffffffa c0000000008ad2c0 c000000000c7faa8 c00000000239a9d0
> NIP [c00000000053b3d4] .scsi_free_queue+0x24/0x90
> LR [c00000000053e5b0] .scsi_alloc_sdev+0x280/0x2e0
> Call Trace:
> [c0000000783c31e0] [c000000000c7faa8] wireless_seq_fops+0x278d0/0x2eb88 (unreliable)
> [c0000000783c3270] [c00000000053e5b0] .scsi_alloc_sdev+0x280/0x2e0
> [c0000000783c3330] [c00000000053eba0] .scsi_probe_and_add_lun+0x390/0xb40
> [c0000000783c34a0] [c00000000053f7ec] .__scsi_scan_target+0x16c/0x650
> [c0000000783c35f0] [c00000000053fd90] .scsi_scan_channel+0xc0/0x100
> [c0000000783c36a0] [c00000000053fefc] .scsi_scan_host_selected+0x12c/0x1c0
> [c0000000783c3750] [c00000000083dcb4] .ipr_probe+0x2c0/0x390
> [c0000000783c3830] [c0000000003f50b4] .local_pci_probe+0x34/0x50
> [c0000000783c38a0] [c0000000003f5f78] .pci_device_probe+0x148/0x150
> [c0000000783c3950] [c0000000004e1e8c] .driver_probe_device+0xdc/0x210
> [c0000000783c39f0] [c0000000004e20cc] .__driver_attach+0x10c/0x110
> [c0000000783c3a80] [c0000000004e1228] .bus_for_each_dev+0x98/0xf0
> [c0000000783c3b30] [c0000000004e1bf8] .driver_attach+0x28/0x40
> [c0000000783c3bb0] [c0000000004e07d8] .bus_add_driver+0x218/0x340
> [c0000000783c3c60] [c0000000004e2a2c] .driver_register+0x9c/0x1b0
> [c0000000783c3d00] [c0000000003f62d4] .__pci_register_driver+0x64/0x140
> [c0000000783c3da0] [c000000000b99f88] .ipr_init+0x4c/0x68
> [c0000000783c3e20] [c00000000000ad24] .do_one_initcall+0x1a4/0x1e0
> [c0000000783c3ee0] [c000000000b512d0] .kernel_init+0x14c/0x1fc
> [c0000000783c3f90] [c000000000022468] .kernel_thread+0x54/0x70
> Instruction dump:
> ebe1fff8 7c0803a6 4e800020 7c0802a6 fba1ffe8 fbe1fff8 7c7f1b78 f8010010
> f821ff71 e8030398 3120ffff 7c090110 <0b000000> e86303b0 482de065 60000000
> ---[ end trace 759bed76a85e8dec ]---
> scsi 0:0:1:0: Direct-Access IBM-ESXS MAY2036RC T106 PQ: 0 ANSI: 5
> ------------[ cut here ]------------
>
> I get lots more of these. The obvious commit to point the finger at
> is 3308511c93e6 ("[SCSI] Make scsi_free_queue() kill pending SCSI
> commands") but the root cause may be something different.
Caused by
commit f7c9c6bb14f3104608a3a83cadea10a6943d2804
Author: Anton Blanchard <anton@samba.org>
Date: Thu Nov 3 08:56:22 2011 +1100
[SCSI] Fix block queue and elevator memory leak in scsi_alloc_sdev
Doesn't completely do the teardown. The true fix is to do a proper
teardown instead of hand rolling it
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 05ee7964a470d29889ac48cc8274c1b5a1904a11 upstream.
spec->cur_adc isn't set until cs_capture_pcm_prepare() is called although
the driver tries to select the connection at init time and at auto-mic
switch. This results in the access to the widget NID 0, which is
obviously invalid, also a wrong capture source.
This patch fixes the issue by issuing the connect-select verb conditionally
at appropriate places.
Reported-and-tested-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit c75d720fca8a91ce99196d33adea383621027bf2 upstream.
commit d05c65fff0 ("genirq: spurious: Run only one poller at a time")
introduced a regression, leaving the boot options 'irqfixup' and
'irqpoll' non-functional. The patch placed tests in each function, to
exit if the function is already running. The test in 'misrouted_irq'
exited when it should have proceeded, effectively disabling
'misrouted_irq' and 'poll_spurious_irqs'.
The check for an already running poller needs to be "!= 1" not "== 1"
as "1" is the value when the first poller starts running.
Signed-off-by: Edward Donovan <edward.donovan@numble.net>
Cc: maciej.rutecki@gmail.com
Link: http://lkml.kernel.org/r/1320175784-6745-1-git-send-email-edward.donovan@numble.net
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
commit 6b76106d8ef31111d6fc469564b83b5f5542794f upstream.
Even after commit 5478755616ae2ef1ce144dded589b62b2a50d575
("block: check for proper length of iov entries earlier ...")
we still won't check for zero-length entries after an unaligned
entry. Remove the break-statement, so all entries are checked.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 7a401a972df8e184b3d1a3fc958c0a4ddee8d312 upstream.
bdi_prune_sb() in bdi_unregister() attempts to removes the bdi links
from all super_blocks and then del_timer_sync() the writeback timer.
However, this can race with __mark_inode_dirty(), leading to
bdi_wakeup_thread_delayed() rearming the writeback timer on the bdi
we're unregistering, after we've called del_timer_sync().
This can end up with the bdi being freed with an active timer inside it,
as in the case of the following dump after the removal of an SD card.
Fix this by redoing the del_timer_sync() in bdi_destory().
------------[ cut here ]------------
WARNING: at /home/rabin/kernel/arm/lib/debugobjects.c:262 debug_print_object+0x9c/0xc8()
ODEBUG: free active (active state 0) object type: timer_list hint: wakeup_timer_fn+0x0/0x180
Modules linked in:
Backtrace:
[<c00109dc>] (dump_backtrace+0x0/0x110) from [<c0236e4c>] (dump_stack+0x18/0x1c)
r6:c02bc638 r5:00000106 r4:c79f5d18 r3:00000000
[<c0236e34>] (dump_stack+0x0/0x1c) from [<c0025e6c>] (warn_slowpath_common+0x54/0x6c)
[<c0025e18>] (warn_slowpath_common+0x0/0x6c) from [<c0025f28>] (warn_slowpath_fmt+0x38/0x40)
r8:20000013 r7:c780c6f0 r6:c031613c r5:c780c6f0 r4:c02b1b29
r3:00000009
[<c0025ef0>] (warn_slowpath_fmt+0x0/0x40) from [<c015eb4c>] (debug_print_object+0x9c/0xc8)
r3:c02b1b29 r2:c02bc662
[<c015eab0>] (debug_print_object+0x0/0xc8) from [<c015f574>] (debug_check_no_obj_freed+0xac/0x1dc)
r6:c7964000 r5:00000001 r4:c7964000
[<c015f4c8>] (debug_check_no_obj_freed+0x0/0x1dc) from [<c00a9e38>] (kmem_cache_free+0x88/0x1f8)
[<c00a9db0>] (kmem_cache_free+0x0/0x1f8) from [<c014286c>] (blk_release_queue+0x70/0x78)
[<c01427fc>] (blk_release_queue+0x0/0x78) from [<c015290c>] (kobject_release+0x70/0x84)
r5:c79641f0 r4:c796420c
[<c015289c>] (kobject_release+0x0/0x84) from [<c0153ce4>] (kref_put+0x68/0x80)
r7:00000083 r6:c74083d0 r5:c015289c r4:c796420c
[<c0153c7c>] (kref_put+0x0/0x80) from [<c01527d0>] (kobject_put+0x48/0x5c)
r5:c79643b4 r4:c79641f0
[<c0152788>] (kobject_put+0x0/0x5c) from [<c013ddd8>] (blk_cleanup_queue+0x68/0x74)
r4:c7964000
[<c013dd70>] (blk_cleanup_queue+0x0/0x74) from [<c01a6370>] (mmc_blk_put+0x78/0xe8)
r5:00000000 r4:c794c400
[<c01a62f8>] (mmc_blk_put+0x0/0xe8) from [<c01a64b4>] (mmc_blk_release+0x24/0x38)
r5:c794c400 r4:c0322824
[<c01a6490>] (mmc_blk_release+0x0/0x38) from [<c00de11c>] (__blkdev_put+0xe8/0x170)
r5:c78d5e00 r4:c74083c0
[<c00de034>] (__blkdev_put+0x0/0x170) from [<c00de2c0>] (blkdev_put+0x11c/0x12c)
r8:c79f5f70 r7:00000001 r6:c74083d0 r5:00000083 r4:c74083c0
r3:00000000
[<c00de1a4>] (blkdev_put+0x0/0x12c) from [<c00b0724>] (kill_block_super+0x60/0x6c)
r7:c7942300 r6:c79f4000 r5:00000083 r4:c74083c0
[<c00b06c4>] (kill_block_super+0x0/0x6c) from [<c00b0a94>] (deactivate_locked_super+0x44/0x70)
r6:c79f4000 r5:c031af64 r4:c794dc00 r3:c00b06c4
[<c00b0a50>] (deactivate_locked_super+0x0/0x70) from [<c00b1358>] (deactivate_super+0x6c/0x70)
r5:c794dc00 r4:c794dc00
[<c00b12ec>] (deactivate_super+0x0/0x70) from [<c00c88b0>] (mntput_no_expire+0x188/0x194)
r5:c794dc00 r4:c7942300
[<c00c8728>] (mntput_no_expire+0x0/0x194) from [<c00c95e0>] (sys_umount+0x2e4/0x310)
r6:c7942300 r5:00000000 r4:00000000 r3:00000000
[<c00c92fc>] (sys_umount+0x0/0x310) from [<c000d940>] (ret_fast_syscall+0x0/0x30)
---[ end trace e5c83c92ada51c76 ]---
Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit d715e433b7ad19c02fc4becf0d5e9a59f97925de upstream.
kdump fails because we try to execute an HV only instruction. Feature
fixups are being applied after we copy the exception vectors down to 0
so they miss out on any updates.
We have always had this issue but it only became critical in v3.0
when we added CFAR support (breaks POWER5) and v3.1 when we added
POWERNV (breaks everyone).
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit de1d9248eadd27539eba449b4d09428252e80c04 upstream.
If you build with KVM and UP it fails with the following due to a
missing include.
/arch/powerpc/kvm/book3s_hv.c: In function 'do_h_register_vpa':
arch/powerpc/kvm/book3s_hv.c:156:10: error: 'H_PARAMETER' undeclared (first use in this function)
arch/powerpc/kvm/book3s_hv.c:156:10: note: each undeclared identifier is reported only once for each function it appears in
arch/powerpc/kvm/book3s_hv.c:192:12: error: 'H_RESOURCE' undeclared (first use in this function)
arch/powerpc/kvm/book3s_hv.c:222:9: error: 'H_SUCCESS' undeclared (first use in this function)
arch/powerpc/kvm/book3s_hv.c: In function 'kvmppc_pseries_do_hcall':
arch/powerpc/kvm/book3s_hv.c:228:30: error: 'H_SUCCESS' undeclared (first use in this function)
arch/powerpc/kvm/book3s_hv.c:232:7: error: 'H_CEDE' undeclared (first use in this function)
arch/powerpc/kvm/book3s_hv.c:234:7: error: 'H_PROD' undeclared (first use in this function)
arch/powerpc/kvm/book3s_hv.c:238:10: error: 'H_PARAMETER' undeclared (first use in this function)
arch/powerpc/kvm/book3s_hv.c:250:7: error: 'H_CONFER' undeclared (first use in this function)
arch/powerpc/kvm/book3s_hv.c:252:7: error: 'H_REGISTER_VPA' undeclared (first use in this function)
make[2]: *** [arch/powerpc/kvm/book3s_hv.o] Error 1
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 72f3bea075287785ed32b777b6dd2636aa7002e8 upstream.
Fixes the PS3 bootup hang introduced in 3.0-rc1 by:
commit 317f394160e9beb97d19a84c39b7e5eb3d7815a
sched: Move the second half of ttwu() to the remote cpu
Move the PS3's LV1 EOI call lv1_end_of_interrupt_ext() from ps3_chip_eoi()
to ps3_get_irq() for IPI messages.
If lv1_send_event_locally() is called between a previous call to
lv1_send_event_locally() and the coresponding call to
lv1_end_of_interrupt_ext() the second event will not be delivered to the
target cpu.
The PS3's SMP IPIs are implemented using lv1_send_event_locally(), so if two
IPI messages of the same type are sent to the same target in a relatively
short period of time the second IPI event can become lost when
lv1_end_of_interrupt_ext() is called from ps3_chip_eoi().
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 99cb2ddcc617f43917e94a4147aa3ccdb2bcd77e upstream.
gref->gref_id is unsigned so the error handling didn't work.
gnttab_grant_foreign_access() returns an int type, so we can add a
cast here, and it doesn't cause any problems.
gnttab_grant_foreign_access() can return a variety of errors
including -ENOSPC, -ENOSYS and -ENOMEM.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 21643e69a4c06f7ef155fbc70e3fba13fba4a756 upstream.
On 32 bit systems a high value of op.count could lead to an integer
overflow in the kzalloc() and gref_ids would be smaller than
expected. If the you triggered another integer overflow in
"if (gref_size + op.count > limit)" then you'd probably get memory
corruption inside add_grefs().
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 90d4f5534d14815bd94c10e8ceccc57287657ecc upstream.
PVHVM running with more than 32 vcpus and pv_irq/pv_time enabled
need VCPU placement to work, or else it will softlockup.
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit f09ee0451a44a4e913a7c3cec3805508f7de6c54 upstream.
The codec for Devkit8000 (TWL4030) was not detected except
when build with CONFIG_SND_SOC_ALL_CODECS.
twl-core.c still uses the CONFIG_TWL4030_CODEC for
twl_has_codec().
In commit 57fe7251f5bfc4332f24479376de48a1e8ca6211
the CONFIG_TWL4030_CODEC was renamed
into CONFIG_MFD_TWL4030_AUDIO, thatswhy the codec
was not detected.
This patch renames the CONFIG_ TWL4030_CODEC into
CONFIG_MFD_TWL4030_AUDIO in twl-core.c.
Signed-off-by: Thomas Weber <weber@corscience.de>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
[This patch is supposed to be applied in 3.1 (and maybe older) branches only.]
New kernels support newer firmware that users may try to incorrectly use
with older kernels. Display error and explain the problem in such a case
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 5a84d6ad4c9306afb467a600a4c6d7b50da49440 upstream.
The brcmsmac driver supports different rates on 5GHz but this is not
taken into account when providing the rate index in the receive
status information passed to mac80211.
Reviewed-by: Roland Vossen <rvossen@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Henry Ptasinski <henryp@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit b872a37437e93df9d112ce674752b3b3a0a17020 upstream.
Noticed by Egbert.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Egbert Eich <eich@suse.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit cb871513f656bdfc48b185b55f37857b5c750c40 upstream.
Revert commit 6123b0e274503a0d3588e84fbe07c9aa01bfaf5d.
The problem this patch intends to solve has alreadqy been fixed by
commit 7a5caabd090b ("drivers/leds/ledtrig-timer.c: fix broken sysfs
delay handling").
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Cc: Antonio Ospite <ospite@studenti.unina.it>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit bc5b8a9003132ae44559edd63a1623b7b99dfb68 upstream.
On a corrupted file system the ->len field could be wrong leading to
a buffer overflow.
Reported-and-acked-by: Clement LECIGNE <clement.lecigne@netasq.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 9f35a33b8d06263a165efe3541d9aa0cdbd70b3b upstream.
Fix a NULL pointer deref in the user-defined key type whereby updating a
negative key into a fully instantiated key will cause an oops to occur
when the code attempts to free the non-existent old payload.
This results in an oops that looks something like the following:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
IP: [<ffffffff81085fa1>] __call_rcu+0x11/0x13e
PGD 3391d067 PUD 3894a067 PMD 0
Oops: 0002 [#1] SMP
CPU 1
Pid: 4354, comm: keyctl Not tainted 3.1.0-fsdevel+ #1140 /DG965RY
RIP: 0010:[<ffffffff81085fa1>] [<ffffffff81085fa1>] __call_rcu+0x11/0x13e
RSP: 0018:ffff88003d591df8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000006e
RDX: ffffffff8161d0c0 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff88003d591e18 R08: 0000000000000000 R09: ffffffff8152fa6c
R10: 0000000000000000 R11: 0000000000000300 R12: ffff88003b8f9538
R13: ffffffff8161d0c0 R14: ffff88003b8f9d50 R15: ffff88003c69f908
FS: 00007f97eb18c720(0000) GS:ffff88003bd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 000000003d47a000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process keyctl (pid: 4354, threadinfo ffff88003d590000, task ffff88003c78a040)
Stack:
ffff88003e0ffde0 ffff88003b8f9538 0000000000000001 ffff88003b8f9d50
ffff88003d591e28 ffffffff810860f0 ffff88003d591e68 ffffffff8117bfea
ffff88003d591e68 ffffffff00000000 ffff88003e0ffde1 ffff88003e0ffde0
Call Trace:
[<ffffffff810860f0>] call_rcu_sched+0x10/0x12
[<ffffffff8117bfea>] user_update+0x8d/0xa2
[<ffffffff8117723a>] key_create_or_update+0x236/0x270
[<ffffffff811789b1>] sys_add_key+0x123/0x17e
[<ffffffff813b84bb>] system_call_fastpath+0x16/0x1b
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Jeff Layton <jlayton@redhat.com>
Acked-by: Neil Horman <nhorman@redhat.com>
Acked-by: Steve Dickson <steved@redhat.com>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit dcaaf9f2c16b56f8bb316881fcd3f15c18fc71e7 upstream.
In the recent usb-audio driver, the initialization of volume ranges
may be delayed when the device doesn't respond well at the probing time.
But the volume quirks for certain devices are applied only in
mixer_ctl_feature_info() thus only at the very first probe and will be
missing when the volume range is initialized later.
This patch moves the volume quirk code to be always called from the
volume-range extraction (get_min_max()), so that the quirks are properly
applied in the later init time.
Reported-and-tested-by: Alexey Fisher <bug-track@fisher-privat.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 9fcd0ab130579d9742538340edda3225f2b49a3e upstream.
When the initial check of dB-range failed due to the read error, try to
check again at the later read, too. When an invalid dB range is found,
remove TLV flags and notify the mixer info change.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 091264f0bc12419560ac64fcef4567809d611658 upstream.
Can happen when there is no DP panel attached, confusing
users. Make it debug only.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 5e60ee780e792efe6dce97eceb110b1d30bab850 upstream.
Fence lock needs to be initialized before any call to nouveau_channel_put
because it calls nouveau_channel_idle->nouveau_fence_update which uses
fence lock.
BUG: spinlock bad magic on CPU#0, test/24134
lock: ffff88019f90dba8, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
Pid: 24134, comm: test Not tainted 3.0.0-nv+ #800
Call Trace:
spin_bug+0x9c/0xa3
do_raw_spin_lock+0x29/0x13c
_raw_spin_lock+0x1e/0x22
nouveau_fence_update+0x2d/0xf1
nouveau_channel_idle+0x22/0xa0
nouveau_channel_put_unlocked+0x84/0x1bd
nouveau_channel_put+0x20/0x24
nouveau_channel_alloc+0x4ec/0x585
nouveau_ioctl_fifo_alloc+0x50/0x130
drm_ioctl+0x289/0x361
do_vfs_ioctl+0x4dd/0x52c
sys_ioctl+0x42/0x65
system_call_fastpath+0x16/0x1b
It's easily triggerable from userspace.
Additionally remove double initialization of chan->fence.pending.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
