Hold the hardware lock while do the response completion in work queue threads as
it involves sharing a common request queue among multiple threads.
Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
Signed-off-by: Giridhar Malavali <giridhar.malavali@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
When the hba port gets logged out of the fabric, or other
such transitional state when the physical link is still present,
the driver doesn't receive a loop up asyn event (where the link
data rate currently gets set). Hence send a explicit mailbox command
to get the link rate in such conditions.
Signed-off-by: Giridhar Malavali <giridhar.malavali@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Fix a target login issue, when parent interface is vlan and we are
using cxgb3i sepecific private ip address in '/etc/iscsi/ifaces/'
iface file.
Signed-off-by: Rakesh Ranjan <rakesh@chelsio.com>
Acked-by: Karen Xie <kxie@chelsio.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Add is_signed_type() call to trace_define_field() in ftrace macros.
The code previously just passed in 0 (false), disregarding whether
or not the field was actually a signed type.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4B273D3A.6020007@cn.fujitsu.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
The struct syscall_metadata variable name in SYSCALL_DEFINE0
should be __syscall_meta__##sname instead of __syscall_meta_##sname
to match the name that is in SYSCALL_DEFINE1/2/3/4/5/6.
This error causes event_enter_##sname->data to point to the wrong
location, which causes syscalls which are defined by SYSCALL_DEFINE0()
not to be traced.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4B273D2E.1010807@cn.fujitsu.com>
Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
The format files of trace_kprobe do not show the sign of the fields.
The other format files show the field signed type of the fields and
this patch makes the trace_kprobe formats consistent with the others.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4B273D27.5040009@cn.fujitsu.com>
Acked-by: Masami Hiramatsu <mhiramat@redhat.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
with CONFIG_GART_IOMMU enabled drivers/char/agp/amd64-agp.c has:
#ifndef CONFIG_GART_IOMMU
module_init(agp_amd64_init);
module_exit(agp_amd64_cleanup);
#endif
agp_amd64_init() was called via gart_iommu_init with
CONFIG_GART_IOMMU=y agp_amd64_init() was called via module_init
with CONFIG_GART_IOMMU=n
The commit 75f1cdf1dd changes the
x86 dma initialization routine: gart_iommu_init() is called only
when GART IOMMU is detected. So when GART IOMMU isn't detected,
agp_amd64_init isn't called.
Marin Mitov reported this issue:
http://marc.info/?l=linux-kernel&m=126192729110083&w=2
With this patch, agp_amd64_init() is always called via
module_init (the above ifndef is removed). If agp_amd64_init()
is called via gart_iommu_init() earlier, agp_amd64_init()
finishes without doing anything (when it is called via
module_init).
Reported-by: Marin Mitov <mitov@issp.bas.bg>
Tested-by: Marin Mitov <mitov@issp.bas.bg>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: davej@redhat.com
LKML-Reference: <20091228181118C.fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
It would appear that in BIOS's with nVidia hooks, the GUID
05901221-D566-11D1-B2F0-00A0C9062910 is duplicated. For now, the simplest
solution is to just ignore any duplicate GUIDs. These particular hooks are not
currently supported/ used in the kernel, so whoever does that can figure out
what the 'right' solution should be (if there's a better one).
http://bugzilla.kernel.org/show_bug.cgi?id=14846
Signed-off-by: Carlos Corbacho <carlos@strangeworlds.co.uk>
Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
Reported-by: Oldřich Jedlička <oldium.pro@seznam.cz>
Signed-off-by: Len Brown <len.brown@intel.com>
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The commit 1fdd407f4e incorrectly made driver
abort loading when known GUID is present when it should have done exactly
the opposite.
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Len Brown <len.brown@intel.com>
When acpi_evaluate_object() is passed ACPI_ALLOCATE_BUFFER,
the caller must kfree the returned buffer if AE_OK is returned.
The callers of wmi_get_event_data() pass ACPI_ALLOCATE_BUFFER,
and thus must check its return value before accessing
or kfree() on the buffer.
Signed-off-by: Len Brown <len.brown@intel.com>
Emphasize that that wmi_install_notify_handler() returns an acpi_status
rather than -errno by by testing ACPI_SUCCESS(), ACPI_FAILURE().
No functional change in this patch, but this confusion caused a bug in dell-wmi.
Signed-off-by: Len Brown <len.brown@intel.com>
follow 0/-E convention
wmi_install_notify_handler() returns an acpi_error,
but dell_wmi_init() needs return a -errno style error.
Tested-by: Paul Rolland <rol@as2917.net>
Signed-off-by: Len Brown <len.brown@intel.com>
blk_rq_err_sectors() seems useless, get rid of it.
Signed-off-by: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Lifebook protocol can only be activated if we find known DMI signature.
It is useles without DMI.
Reported-by: Rakib Mullick <rakib.mullick@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
This should fix the following compile warning:
drivers/input/misc/wistron_btns.c:1331:5: warning: "CONFIG_PM" is not defined
Signed-off-by: Rakib Mullick <rakib.mullick@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
backlight_device_register may return an ERR_PTR
value rather than a valid pointer.
Problem found by Julia Lawall, properly fixed by Zhang Rui.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Len Brown <len.brown@intel.com>
trace_stat is problematic. Don't use it, use seqfile instead.
This fixes a race that reading the stat file is not protected by
any lock, which can lead to use after free.
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: K.Prasad <prasad@linux.vnet.ibm.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
LKML-Reference: <4B3AF203.40200@cn.fujitsu.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
We are under rcu read section but not holding the write lock, so
count++ is not atomic. Use atomic64_t instead.
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: K.Prasad <prasad@linux.vnet.ibm.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
LKML-Reference: <4B3AF1EC.9010608@cn.fujitsu.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
It used to work, but now doesn't:
# echo > ksym_filter
bash: echo: write error: Invalid argument
It's caused by d954fbf0ff
("tracing: Fix wrong usage of strstrip in trace_ksyms").
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: K.Prasad <prasad@linux.vnet.ibm.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
LKML-Reference: <4B3AF1D7.5040400@cn.fujitsu.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
ksym tracer doesn't work:
# echo tasklist_lock:rw- > ksym_trace_filter
-bash: echo: write error: No such device
It's because we pass to perf_event_create_kernel_counter()
a cpu number which is not present.
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: K.Prasad <prasad@linux.vnet.ibm.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
LKML-Reference: <4B3AF19E.1010201@cn.fujitsu.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
AML code always sends notifications to ACPI video device,
even if we disable the ACPI backlight control by using
boot option "acpi_backlight=vendor".
In this case we should not print any warning message.
http://bugzilla.kernel.org/show_bug.cgi?id=13671#c14
Sigend-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Today's -tip failed to build because commit
9e368fa011 ("ipmi: add PNP discovery (ACPI
namespace via PNPACPI)") from today's upstream kernel causes the following
build failure on x86, for CONFIG_ACPI=n && CONFIG_IPMI_SI=y:
drivers/char/ipmi/ipmi_si_intf.c:3208: error: 'ipmi_pnp_driver' undeclared (first use in this function)
drivers/char/ipmi/ipmi_si_intf.c:3208: error: (Each undeclared identifier is reported only once
drivers/char/ipmi/ipmi_si_intf.c:3208: error: for each function it appears in.)
drivers/char/ipmi/ipmi_si_intf.c:3334: error: 'ipmi_pnp_driver' undeclared (first use in this function)
The reason is that the ipmi_pnp_driver depends on ACPI facilities and is only
made available under ACPI - while the registration and unregistration is made
dependent on CONFIG_PNP:
#ifdef CONFIG_PNP
pnp_register_driver(&ipmi_pnp_driver);
#endif
The solution is to only register this driver under ACPI. (Also, the CONFIG_PNP
dependency is not needed because pnp_register_driver() is stubbed out in the
!CONFIG_PNP case.)
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Acked-by: Myron Stowe <myron.stowe@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This fixes a bug (found by Curt Wohlgemuth) in which new blocks
returned from an extent created with ext4_ext_zeroout() can have dirty
metadata still associated with them.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Curt Wohlgemuth <curtw@google.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If two arrays share a device, then they will not both resync at the
same time. One will wait for the other to complete.
While waiting, the MD_RECOVERY_INTR flag is not checked so a device
failure, which would make the resync pointless, does not cause the
resync to abort, so the failed device cannot be removed (as it cannot
be remove while a resync is happening).
So add a test for MD_RECOVERY_INTR.
Reported-by: Brett Russ <bruss@netezza.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Since commit dfc7064500,
->hot_remove_disks has not removed non-failed devices from
an array until recovery is no longer possible.
So the code in do_md_run to get around the fact that
md_check_recovery (which calls ->hot_remove_disks) would
remove partially-in-sync devices is no longer needed.
So remove it.
Signed-off-by: NeilBrown <neilb@suse.de>
By default md_do_sync() will perform recovery if no other actions are
specified. However, action_show() relies on MD_RECOVERY_RECOVER to be
set otherwise it returns 'idle'. So, add a missing set
MD_RECOVERY_RECOVER when starting recovery.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
The start_ro modules parameter can be used to force arrays to be
started in 'auto-readonly' in which they are read-only until the first
write. This ensures that no resync/recovery happens until something
else writes to the device. This is important for resume-from-disk
off an md array.
However if an array is started 'readonly' (by writing 'readonly' to
the 'array_state' sysfs attribute) we want it to be really 'readonly',
not 'auto-readonly'.
So strengthen the condition to only set auto-readonly if the
array is not already read-only.
Signed-off-by: NeilBrown <neilb@suse.de>
Use the %pM kernel extension to display the MAC address.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use the %pM kernel extension to display the MAC address.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use the %pM kernel extension to display the MAC address.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use the %pM kernel extension to display the MAC address.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use the %pM kernel extension to display the MAC address.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use the %pM kernel extension to display the MAC address.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use the %pM kernel extension to display the MAC address.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use the %pM kernel extension to display the MAC address.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use the %pM kernel extension to display the MAC address.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use the %pM kernel extension to display the MAC address.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use the %pM kernel extension to display the MAC address.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use the %pM kernel extension to display the MAC address.
The only difference in the output is that the MAC address is
shown in the usual colon-separated hex notation instead of
space-separated.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
evms configures md arrays by:
open device
send ioctl
close device
for each different ioctl needed.
Since 2.6.29, the device can disappear after the 'close'
unless a significant configuration has happened to the device.
The change made by "SET_ARRAY_INFO" can too minor to stop the device
from disappearing, but important enough that losing the change is bad.
So: make sure SET_ARRAY_INFO sets mddev->ctime, and keep the device
active as long as ctime is non-zero (it gets zeroed with lots of other
things when the array is stopped).
This is suitable for -stable kernels since 2.6.29.
Signed-off-by: NeilBrown <neilb@suse.de>
Cc: stable@kernel.org
