* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6:
mfd: Avoid twl6040-codec PLL reconfiguration when not needed
mfd: Store twl6040-codec mclk configuration
Some devices (iwl5100) cannot connect to zd1211rw based AP. It appears that
zd1211 firmware messes up duration_id field if it is not set to zero by driver.
Sniffing traffic shows that zd1211 is transmitting frames with duration_id bits
14 and 15 set and other bits appearing random. Setting duration_id at driver to
zero results zd1211 outputting sane duration_id. This means that firmware is
setting correct values itself and expects duration_id to be zero in first
place.
Looking at vendor driver shows that only PSPoll frames have duration_id set by
driver, for other frames duration_id left zero.
Original bug-report and attached patch at:
http://sourceforge.net/mailarchive/message.php?msg_id=28759111
Reported-by: Tomas Vanek <Tomas.Vanek@fbl.cz>
[modified original patch from bug-report, added check for pspoll frame]
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
8<----------------------------------------------------------------------
From: Ralf Roesch <ralf.roesch@rw-gmbh.de>
Date: Wed, 16 Nov 2011 09:33:50 +0100
Subject: [PATCH] net: enable TC35815 for MIPS again
TX493[8,9] MIPS SoCs support 2 Ethernet channels of type TC35815
which are connected to the internal PCI controller.
And JMR3927 MIPS board has a TC35815 chip on board.
These dependencies were lost on movement to drivers/net/ethernet/toshiba.
Signed-off-by: Ralf Roesch <ralf.roesch@rw-gmbh.de>
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
CC: stable@vger.kernel.org [3.2+]
Signed-off-by: David S. Miller <davem@davemloft.net>
When this GETHER controller received a large frame (about 1800 bytes
or more), skb_over_panic() happened. This is because the previous
driver set the RFLR to 0x1000 (4096 bytes) and the skb allocate size
is smaller than 4096 bytes. So, the controller accepted such a frame.
The controller can discard a large frame by the RFLR setting.
So, the patch modifies the value of RFLR to mtu + ETH_HLEN +
VLAN_HLEN + ETH_FCS_LEN.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We allocate memory for 'new_data' with kmalloc(). If we get the memory
we then try to build_skb() and if that should fail (which it can) we
do not enter 'if (likely(skb)) {' and actually use 'new_data' but
instead fall through to the 'drop:' label and end up returning from
the function without ever assigning 'new'data' to anything or freeing
it. That leaks the memory allocated to 'new_data'.
This patch fixes the memory leak by doing a kfree(new_data) in the
case where build_skb() fails (or where allocation of 'new_data' itself
fails, but in taht case it's just a harmless kfree(NULL)).
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Eilon Greenstein <eilong@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
As it is, with PCI/ISA/MCA/CCW all set to n and PCMCIA set to m
setting TR to y will set LLC to m, with very unpleasant results -
net/802/psnap gets picked into obj-y, resulting in the kernel
that won't link - psnap calls functions from llc. The cause,
AFAICS, is that kconfig gets rev_dep for LLC containing
|| TR && (deps for TR)
and even though TR is boolean, both LLC and PCMCIA are tristate
and that thing becomes || y && (n || m), i.e. || m. The reason
for dependency on PCMCIA is that when none of PCI, ISA, MCA, CCW
or PCMCIA is set there'll be no tokenring drivers, so there's no
point building tokenring core. Proper fix probably belongs in
kconfig (we need strict and, such that y <strict_and> m would be
y, so that rev_deps added for tristate selected by bool would
use that instead of &&; we'd have || TR <strict_and> (deps for TR)
in this case), but it's a rather intrusive change. There's an
easy workaround in case of TR -> LLC select, namely to have a def_bool y
symbol sitting under if TR and have that symbol selecting LLC.
Kudos to johill for suggesting that one...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
As reported by several people...
The code in rx_clean was panic'ing so revert
commit d0249e4443.
Will redo DMA mapping checks as new patches for a later release.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The following patch fixes a bug introduced by the following
commit:
e050e3f0a7 ("perf: Fix broken interrupt rate throttling")
The patch caused the following warning to pop up depending on
the sampling frequency adjustments:
------------[ cut here ]------------
WARNING: at arch/x86/kernel/cpu/perf_event.c:995 x86_pmu_start+0x79/0xd4()
It was caused by the following call sequence:
perf_adjust_freq_unthr_context.part() {
stop()
if (delta > 0) {
perf_adjust_period() {
if (period > 8*...) {
stop()
...
start()
}
}
}
start()
}
Which caused a double start and a double stop, thus triggering
the assert in x86_pmu_start().
The patch fixes the problem by avoiding the double calls. We
pass a new argument to perf_adjust_period() to indicate whether
or not the event is already stopped. We can't just remove the
start/stop from that function because it's called from
__perf_event_overflow where the event needs to be reloaded via a
stop/start back-toback call.
The patch reintroduces the assertion in x86_pmu_start() which
was removed by commit:
84f2b9b ("perf: Remove deprecated WARN_ON_ONCE()")
In this second version, we've added calls to disable/enable PMU
during unthrottling or frequency adjustment based on bug report
of spurious NMI interrupts from Eric Dumazet.
Reported-and-tested-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Stephane Eranian <eranian@google.com>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: markus@trippelsdorf.de
Cc: paulus@samba.org
Link: http://lkml.kernel.org/r/20120207133956.GA4932@quad
[ Minor edits to the changelog and to the code ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
This hardware requires same fixup for the node 0x0f like Asus A6Rp.
More information: https://bugzilla.redhat.com/show_bug.cgi?id=785417
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Analogically to d7cb3dbd1 ("HID: wacom: Fix invalid power_supply_powers
calls"), fix also the same occurence in wiimote driver.
Reported-by: przemo@firszt.eu
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
In patch_ca0132.c, the error returned from chipio_write() isn't checked
always. Also, the power-up/down sequence isn't tracked properly in some
error paths.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
the Android suspend ignore code for idle_bias_off CODECs. That one is
actually a regression fix as some of the new power savings that have
been introduced confused the suspend ignore code, making devices that
are active for non-audio reasons look like they are idle causing them to
be suspended instead of being kept active.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJPLSlpAAoJEBus8iNuMP3d0JkP/jA3bSbSR2/qg0SeOP1uEN9G
5JBD12urid3+cPi8FzBw3ecIH2thf1SoSg8rL//4gENyX6N9Ia1jXNjhYsA701kH
7EXsCqmMBl9qUfVTaGGAIh1SsRbNVuSQlL5KmG3yQPwRooNX+K/slr6BuItUepzz
H4C1bl45a92Wh6Nc1t+jYDJXS5Z+o5fc45AVpeiw+xcPblFcXptKVuWpHXfBHgef
+qK8SpfrvKfGygrFnLteYIwDby7ZPA21znRiBjPg2jL+w3KsIgOlZWbWJHZdlJ7/
5oSKaYXYbuA3UCUBayteakeDqiAoxjv4aw6XzAVgtwaITyuOdkWtLjvmSVFAElF4
J0u7/CukK434qezds9bztaBqigoEpRj4EH0Dd5ybZi1vOJO5V9UA8/SNux+K6yWX
+MHizTDZFlZNMdYsoCfinVlpelmvNl1TJYTL7JLKMUmE0+ph2Jz6elgbIkvlwHFb
bEjm/+fLZIHnzam88FikmbAER96w/pc7EtFFXmWKDkQwy9wDvnt4wNhy/MhwXub3
XiMkmcb+cCoaN5nefs49mYvIMUP90INfLWTn8r30GqbByEWdASC4sj5GSC6Ak7/G
Y4e90zxFd10UiaZMFoGmfcMBQ49ZKNGgxJ3aWPoz7dfM8MI6Gy9qcLyoDWBlwBFN
uh159btp7tVAn4D/wgC+
=FOxW
-----END PGP SIGNATURE-----
Merge tag 'asoc-3.3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
The only particularly remarkable change here is the one for handling of
the Android suspend ignore code for idle_bias_off CODECs. That one is
actually a regression fix as some of the new power savings that have
been introduced confused the suspend ignore code, making devices that
are active for non-audio reasons look like they are idle causing them to
be suspended instead of being kept active.
Removed the following:
* irrelevant argument 'barrier' of mtip_hw_submit_io()
* unused member 'eh_active' of struct driver_data
Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
Signed-off-by: Sam Bradshaw <sbradshaw@micron.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
put_io_context() performed a complex trylock dancing to avoid
deferring ioc release to workqueue. It was also broken on UP because
trylock was always assumed to succeed which resulted in unbalanced
preemption count.
While there are ways to fix the UP breakage, even the most
pathological microbench (forced ioc allocation and tight fork/exit
loop) fails to show any appreciable performance benefit of the
optimization. Strip it out. If there turns out to be workloads which
are affected by this change, simpler optimization from the discussion
thread can be applied later.
Signed-off-by: Tejun Heo <tj@kernel.org>
LKML-Reference: <1328514611.21268.66.camel@sli10-conroe>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
This patch fixes a bug in target-core where unsupported WRITE_SAME ops
from a target_check_write_same_discard() failure was incorrectly
returning CHECK_CONDITION w/ TCM_INVALID_CDB_FIELD sense data.
This was causing some clients to not properly fall back, so go ahead
and use the correct TCM_UNSUPPORTED_SCSI_OPCODE sense for this case.
Reported-by: Martin Svec <martin.svec@zoner.cz>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Use IP_FREEBIND socket option so that iscsi portal configuration with
explicit IP addresses can happen during boot, before network interfaces
have been assigned IPs.
This is especially important on systemd based Linux boxes where system
boot happens asynchronously and non-trivial configuration must be done
to get targetcli.service to start synchronously after the network is
configured.
Reference:
http://lists.fedoraproject.org/pipermail/devel/2011-October/158025.html
Signed-off-by: Dax Kelson <dkelson@gurulabs.com>
Cc: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Cc: "Andy Grover" <agrover@redhat.com>
Cc: "Lennart Poettering" <lennart@poettering.net>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Requesting to many bvecs upsets bio_alloc_bioset, so limit the number we ask
for to the amount it can handle.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
These are root only and we're not likely to hit the problem in practise,
but it makes the static checkers happy.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Fixes this error after a recent nfs cleanup:
drivers/target/iscsi/iscsi_target_configfs.c: In function 'lio_target_call_addnptotpg':
drivers/target/iscsi/iscsi_target_configfs.c:214:3: error: implicit declaration of function 'in6_pton' [-Werror=implicit-function-declaration]
drivers/target/iscsi/iscsi_target_configfs.c:239:3: error: implicit declaration of function 'in_aton' [-Werror=implicit-function-declaration]
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
The block layer keeps q->limits.discard_granularity in bytes, but iblock
(and the SCSI Block Limits VPD page) keep unmap_granularity in blocks.
Report the correct value when exporting block devices by dividing to
convert bytes to blocks.
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
This patch fixes a bug in target_submit_cmd() where the failure path
for transport_generic_allocate_tasks() made a direct call to
transport_send_check_condition_and_sense() and not calling the
final target_put_sess_cmd() release callback.
For transport_generic_allocate_tasks() failures, use the proper call to
transport_generic_request_failure() to handle kref_put() along
with potential internal queue full response processing.
It also makes transport_lookup_cmd_lun() failures in
target_submit_cmd() use transport_send_check_condition_and_sense() and
target_put_sess_cmd() directly to avoid se_cmd->se_dev reference in
transport_generic_request_failure() handling.
Finally it drops the out_check_cond: label and use direct reference for
allocate task failures, and per-se_device queue_full handling is
currently not supported for transport_lookup_cmd_lun() failure
descriptors due to se_device dependency.
Reported-by: Roland Dreier <roland@purestorage.com>
Cc: Roland Dreier <roland@purestorage.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Retval not very useful, and may even be harmful. Once submitted, fabrics
should expect a sense error if anything goes wrong. All fabrics checking
of this retval are useless or broken:
fc checks it just to emit more debug output.
ib_srpt trickles retval up, then it is ignored.
qla2xxx trickles it up, which then causes a bug because the abort goto
in qla_target.c thinks cmd hasn't been sent to target.
Just returning nothing is best.
Signed-off-by: Andy Grover <agrover@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
WindowsXP+BOT issues a MODE_SENSE request with page 0x1c which is not
suppoerted by target. Target rejects that command with
TCM_INVALID_CDB_FIELD, so far so good. On BOT I can't send the SENSE
response back, instead I can only reply that an error occured. The next
thing happens is a REQUEST_SENSE request with 18 bytes length. Since the
check here is more than 18 bytes I have to NACK that request as well.
This is not really required: We check for some additional room, but we
never use it. The additional length is set to 0xa so the total length is
0xa + 8 = 18 which is fine with my 18 bytes.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
1/ If a resync is aborted we should record how far we got
(recovery_cp) the last request that we know has completed
(->curr_resync_completed) rather than the last request that was
submitted (->curr_resync).
2/ When a resync aborts we still want to update the metadata with
any changes, so set MD_CHANGE_DEVS even if we 'skip'.
Signed-off-by: NeilBrown <neilb@suse.de>
Update quilt tree location for Documentation/ patches.
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Two of the bits in the tainted flag are not documented.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fixing a regression with the PMU MSRs when PMU virtualization is
disabled, a guest-internal DoS with the SYSCALL instruction, and a dirty
memory logging race that may cause live migration to fail.
* 'kvm-updates/3.3' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: do not #GP on perf MSR writes when vPMU is disabled
KVM: x86: fix missing checks in syscall emulation
KVM: x86: extend "struct x86_emulate_ops" with "get_cpuid"
KVM: Fix __set_bit() race in mark_page_dirty() during dirty logging
Straight forward bug fixes in this branch. A couple of x86 gpio drivers
missing spinlock initialization, an API change fixup for the samsung driver
and a name typo fix.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJPL3DuAAoJEEFnBt12D9kB3ZAP/ikN3WkdfTvufg9pxfWW5Mwn
dMuZKRf8tjNVk+orTRc45mgF5w1b9QFfVC90q/hYWExHw34WgkW0yDoWDsnVzuez
q5WpkxVgvc8lPBD/XC/hS9tNoER5AkdS5w5daw5t499jt17euxADmBSmI0N12api
U1AmDuLK6281YbYfGJiFYaSyyVpE582XRm+jM+3SuwPpXeFu56sZk9r/ehEhRoT/
7HjnBmga3REJN3YhUU6545HaD1hXdPCqXg2gYu0T3MCtvtuLAEEnUF6magWLNNfL
JleZz0fQ1YAM/Q0CYU7S6Fib8j9QWgQOkrPRcvt83OMu7gbQT6A2i8tyM2eXhtlJ
qFO3+uXdtrGBAGDT4G4Hdzt91xtKSIwZQZxpa0cZdif/MiFBwbOB6NwNURuOGEHk
6WSQrstZozd6QjeSla+5jrppCJfBgguQ+xixY50xcYnb8xjJrm780UKdySsThXdv
W1WhK2SgkbMztwBspXfx5SNg02udRwolfuVXL2TinPZOmJgnElK+WtJ+1dkyoQTW
OhX4hWYCCi4Ao2qAoghWRCeVksFd6XsJvEZJsO57/URlNbEaE++FyCav/BS51CVe
AP6m0EizXC89XHQW1xWpp5Wcv/8IvC7PfJ9liKXyvjteiSyC7hYlgYqOA9bMn9NP
+G+6mzfJ66qC/Hvq3GkF
=WQ/Y
-----END PGP SIGNATURE-----
Merge tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux-2.6
GPIO fixes for v3.3-rc2
Straight forward bug fixes in this branch. A couple of x86 gpio drivers
missing spinlock initialization, an API change fixup for the samsung driver
and a name typo fix.
* tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux-2.6:
gpio: Add missing spin_lock_init in gpio-ml-ioh driver
gpio: Add missing spin_lock_init in gpio-pch driver
gpio: samsung: adapt to changes in gpio specifier translator function declaration
Correct bad gpio naming
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAABAgAGBQJPLedwAAoJEANmWzN1g3l3F18IAJvV8cvTBDr/OV5wmEHx4v7t
s9l7wfXop2ilsNoAT8mdLwa6ilwatG9k9UhzsF8a2nUR1rNAWA9SFc2v6kLCIZpN
SVQzh9260X5jrRiUn7dKpLwwxDbepcvHFbpei9Xi/ON97ZjUnHEk27tf/s6MI8ad
EvCCJR+Lsw1ara6ZX+kQqznUME46dPZA6A5rxXFbRv8QTIe8++f+KSdXWBt8r3yK
pDfdEGyYwkDoqjUBv2EZ/XMCQdjmdgU9NRExKHJdOyHnea+0RbUik1viuXm7JNQV
Rd9DtC3vjq8qxCLBhJ1Ay5K8TmAbrgAGGjCo98mNY8D0F9NXL4sfyPW7qxCEa3E=
=tYxf
-----END PGP SIGNATURE-----
Merge tag 'hwmon-fixes-for-3.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
One patch to fix fan detection on NCT6776F.
* tag 'hwmon-fixes-for-3.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
hwmon: (w83627ehf) Fix number of fans for NCT6776F
Setting the task name is done within setup_new_exec() by accessing
bprm->filename. However this happens after flush_old_exec().
This may result in a use after free bug, flush_old_exec() may
"complete" vfork_done, which will wake up the parent which in turn
may free the passed in filename.
To fix this add a new tcomm field in struct linux_binprm which
contains the now early generated task name until it is used.
Fixes this bug on s390:
Unable to handle kernel pointer dereference at virtual kernel address 0000000039768000
Process kworker/u:3 (pid: 245, task: 000000003a3dc840, ksp: 0000000039453818)
Krnl PSW : 0704000180000000 0000000000282e94 (setup_new_exec+0xa0/0x374)
Call Trace:
([<0000000000282e2c>] setup_new_exec+0x38/0x374)
[<00000000002dd12e>] load_elf_binary+0x402/0x1bf4
[<0000000000280a42>] search_binary_handler+0x38e/0x5bc
[<0000000000282b6c>] do_execve_common+0x410/0x514
[<0000000000282cb6>] do_execve+0x46/0x58
[<00000000005bce58>] kernel_execve+0x28/0x70
[<000000000014ba2e>] ____call_usermodehelper+0x102/0x140
[<00000000005bc8da>] kernel_thread_starter+0x6/0xc
[<00000000005bc8d4>] kernel_thread_starter+0x0/0xc
Last Breaking-Event-Address:
[<00000000002830f0>] setup_new_exec+0x2fc/0x374
Kernel panic - not syncing: Fatal exception: panic_on_oops
Reported-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It is never correct to use intel_crtc->bpp in intel_dp_link_required,
so instead pass an explicit bpp in to this function. This patch
only supports 18bpp and 24bpp modes, which means that 10bpc modes will
be computed incorrectly. Fixing that will require more extensive
changes, and so must be addressed separately from this bugfix.
intel_dp_link_required is called from intel_dp_mode_valid and
intel_dp_mode_fixup.
* intel_dp_mode_valid is called to list supported modes; in this case,
the current crtc values cannot be relevant as the modes in question
may never be selected. Thus, using intel_crtc->bpp is never right.
* intel_dp_mode_fixup is called during mode setting, but it is run
well before ironlake_crtc_mode_set is called to set intel_crtc->bpp,
so using intel_crtc-bpp in this path can only ever get a stale
value.
Cc: Lubos Kolouch <lubos.kolouch@gmail.com>
Cc: Adam Jackson <ajax@redhat.com>
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42263
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44881
Tested-by: Dave Airlie <airlied@redhat.com>
Tested-by: camalot@picnicpark.org (Dell Latitude 6510)
Tested-by: Roland Dreier <roland@digitalvampire.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
This patch fixes an issue where perf report shows nan% for certain
perf.data files. The below is from a report for a do_fork probe:
-nan% sshd [kernel.kallsyms] [k] do_fork
-nan% packagekitd [kernel.kallsyms] [k] do_fork
-nan% dbus-daemon [kernel.kallsyms] [k] do_fork
-nan% bash [kernel.kallsyms] [k] do_fork
A git bisect shows commit f3bda2c as the cause. However, looking back
through the git history, I saw commit 640c03c which seems to have
removed the required initialization for perf_sample->period. The problem
only started showing after commit f3bda2c. The below patch re-introduces
the initialization and it fixes the problem for me.
With the below patch, for the same perf.data:
73.08% bash [kernel.kallsyms] [k] do_fork
8.97% 11-dhclient [kernel.kallsyms] [k] do_fork
6.41% sshd [kernel.kallsyms] [k] do_fork
3.85% 20-chrony [kernel.kallsyms] [k] do_fork
2.56% sendmail [kernel.kallsyms] [k] do_fork
This patch applies over current linux-tip commit 9949284.
Problem introduced in:
$ git describe 640c03c
v2.6.37-rc3-83-g640c03c
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Robert Richter <robert.richter@amd.com>
Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: stable@kernel.org
Link: http://lkml.kernel.org/r/20120203170113.5190.25558.stgit@localhost6.localdomain6
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
In some perf ancient versions we used '[kernel.kallsyms._text]' as the
name for the kernel map.
This got changed with commit:
perf: 'perf kvm' tool for monitoring guest performance from host
commit a1645ce12a
Author: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
and we started to use following name '[kernel.kallsyms]_text'.
This name change is important for the report code dealing with ancient
perf data. When processing the kernel map event, we need to recognize
the old naming (dont match the last ']') and initialize the kernel map
correctly.
The subsequent call to maps__set_kallsyms_ref_reloc_sym deals with the
superfluous ']' to get correct symbol name.
Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1328461865-6127-1-git-send-email-jolsa@redhat.com
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
By adding following objects:
bench/mem-memcpy-x86-64-asm.o
the x86_64 perf binary ended up with executable stack.
The reason was that above object are assembler sourced and is missing the
GNU-stack note section. In such case the linker assumes that the final binary
should not be restricted at all and mark the stack as RWX.
Adding section ".note.GNU-stack" definition to mentioned object, with all
flags disabled, thus omiting this object from linker stack flags decision.
Problem introduced in:
$ git describe ea7872b
v2.6.37-rc2-19-gea7872b
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=783570
Reported-by: Clark Williams <williams@redhat.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: stable@kernel.org
Link: http://lkml.kernel.org/r/1328100848-5630-1-git-send-email-jolsa@redhat.com
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
[ committer note: Backported fix to perf/urgent (3.3-rc2+) ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
mlx4_en_prepare_rx_desc does not correctly clean up after it finds an
allocation failure. It should unmap a page before calling put_page, but
it only calls the later.
This bug would prevent a device removal using hotplug after setting the
device MTU to 9000 and opening the network interface. After the fix, we
still see the allocation failure with MTU 9000, but we are able to
remove the device.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
After opening the network interface, Mellanox ConnectX device cannot be
removed by hotplug because it has not properly unmapped all DMA memory.
It happens that mlx4_en_activate_rx_rings overrides the variable that
keeps the size of the memory mapped.
This is fixed by passing to mlx4_en_destroy_rx_ring the same size that is
given to mlx4_en_create_rx_ring.
After applying this patch, hot unplugging the device works after opening
the interface.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The brcmsmac driver is now using the bcma SPROM CRC check, which does
not recognize all chipsets that were functional prior to the switch. In
particular, the current code bails out on odd CRC errors in recent
Macbooks. This patch ignores those errors, with the argument that an
unrecognized SPROM should be treated similarly to a non-existing one.
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use port number for correct steering (list per port).
Before the fix all steering entries (for both physical ports)
were managed in first port structures, so we had leakage of resources
for port 2.
Signed-off-by: Eugenia Emantayev <eugenia@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use MLX4_DEV_CAP_FLAG_VEP_UC_STEER for unicast_promisc_add/remove
Unicast entries were managed in wrong data structures.
Signed-off-by: Eugenia Emantayev <eugenia@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
Perform cleanup also in non-master flow.
The VFs use communication channel as well.
Signed-off-by: Eugenia Emantayev <eugenia@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit adb5066 "ath9k_hw: do not apply the 2.4 ghz ack timeout
workaround to cts" reduced the hardware CTS timeout to the normal
values specified by the standard, but it turns out while it doesn't
need the same extra time that it needs for the ACK timeout, it
does need more than the value specified in the standard, but only
for 2.4 GHz.
This patch brings the CTS timeout value in sync with the initialization
values, while still allowing adjustment for bigger distances.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Reported-by: Seth Forshee <seth.forshee@canonical.com>
Reported-by: Marek Lindner <lindner_marek@yahoo.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
commit b4a82a0 "ath9k_hw: fix interpretation of the rx KeyMiss flag"
fixed the interpretation of the KeyMiss flag for keycache based lookups,
however WEP encryption uses a static index, so KeyMiss is always asserted
for it, even though frames are decrypted properly.
Fix this by clearing the ATH9K_RXERR_KEYMISS flag if no keycache based
lookup was performed.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Reported-by: Laurent Bonnans <bonnans.l@gmail.com>
Reported-by: Jurica Vukadin <u.ra604@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If driver load is failed, sometimes few pointers may remain
uninitialized ex. priv->wdev, priv->netdev, adapter->sleep_cfm
This will cause NULL pointer dereferance while unloading the
driver.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kiran Divekar <dkiran@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
power_supply_powers calls added in 35b4c01e2 ("power_supply: add "powers" links
to self-powered HID devices") have to be called after power device is created.
This patch also fixes the second call - it has to be "ac" instead of "battery"
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
Signed-off-by: Chris Bagwell <chris@cnpbagwell.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Sync with Linus' tree. This is necessary to have a base for
patch that fixes commit 35b4c01e29 ("power_supply: add "powers"
links to self-powered HID devices") which went in through Anton's
tree.
We can enable VMID independently of the bias in some use cases so we need
to ensure that the core device is powered up.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org
sparse complains that "spec->multiout.dac_nids" is a pointer.
sound/pci/hda/patch_realtek.c:2321:37: error: incompatible types for operation (>)
sound/pci/hda/patch_realtek.c:2321:37: left side has type unsigned short const [usertype] *dac_nids
sound/pci/hda/patch_realtek.c:2321:37: right side has type int
It was meant to be num_dacs instead of dac_nids.
Although the current code still works as expected (when num_dacs is zero,
dac_nids should be NULL, too), better to fix now, of course.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
