qla2x00_mem_alloc() returns 1 on success and -ENOMEM on failure. On the
one hand the caller assumes non-zero is success but on the other hand
the caller also assumes that it returns an error code.
I've fixed it to return zero on success and a negative error code on
failure. This matches the documentation as well.
[jejb: checkpatch fix]
Fixes: e315cd28b9 ('[SCSI] qla2xxx: Code changes for qla data structure refactoring')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
isci is needlessly tying libata's hands by returning
SAM_STAT_CHECK_CONDITION to some ata errors. Instead, prefer
SAS_PROTO_RESPONSE to let libata (via sas_ata_task_done()) disposition
the device-to-host fis.
For example isci is triggering an HSM Violation where AHCI is showing a
simple media error for the same bus condition:
isci:
ata7.00: failed command: READ VERIFY SECTOR(S)
ata7.00: cmd 40/00:01:00:00:00/00:00:00:00:00/e0 tag 0
res 01/04:00:00:00:00/00:00:00:00:00/e0 Emask 0x3 (HSM violation)
ahci:
ata6.00: failed command: READ VERIFY SECTOR(S)
ata6.00: cmd 40/00:01:00:00:00/00:00:00:00:00/e0 tag 0
res 51/40:01:00:00:00/00:00:00:00:00/e0 Emask 0x9 (media error)
Note that the isci response matches this from sas_ata_task_done():
/* We saw a SAS error. Send a vague error. */
[..]
dev->sata_dev.fis[3] = 0x04; /* status err */
dev->sata_dev.fis[2] = ATA_ERR;
The end effect is that isci is needlessly triggering hard resets when
they are not necessary.
Reported-by: Xun Ni <xun.ni@intel.com>
Tested-by: Nelson Cheng <nelson.cheng@intel.com>
Acked-by: Lukasz Dorau <lukasz.dorau@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
libsas sometimes short circuits timeouts to force commands into error
recovery. It is misleading to log that the command timed-out in
sas_scsi_timed_out() when in fact it was just queued for error handling.
It's also redundant in the case of a true timeout as libata eh will
detect and report timeouts via it's AC_ERR_TIMEOUT facility.
Given that some environments consider "timeout" errors to be indicative
of impending device failure demote the sas_scsi_timed_out() timeout
message to be disabled by default. This parallels ata_scsi_timed_out().
[jejb: checkpatch fix]
Reported-by: Xun Ni <xun.ni@intel.com>
Tested-by: Nelson Cheng <nelson.cheng@intel.com>
Acked-by: Lukasz Dorau <lukasz.dorau@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Send aborts to the firmware via the request/response queue mechanism.
Signed-off-by: Armen Baloyan <armen.baloyan@qlogic.com>
Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
- Fix interpreting the wrong IOCB type for task management
functions in the response path.
- Merge the task management function handling for various adapters.
Signed-off-by: Armen Baloyan <armen.baloyan@qlogic.com>
Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Allow for the capture of a firmware dump but have a sysfs node
(allow_cna_fw_dump) to allow the feature to be enabled/disabled dynamically.
The default is off.
Signed-off-by: Chad Dupuis <chad.dupuis@qlogic.com>
Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Tell the mid-layer that number of commands we can queue is the available
resources we have minus a small amount for internal commands.
Signed-off-by: Chad Dupuis <chad.dupuis@qlogic.com>
Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
SCSI retry delay upon SAM_STAT_BUSY/_SET_FULL was not being handled
in bnx2fc. This patch adds such handling by returning TARGET_BUSY
to the SCSI ML for the corresponding LUN until the retry timer expires.
Signed-off-by: Eddie Wai <eddie.wai@broadcom.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
The problem has been identified to be a change in the scsi_remove_device
path where a call to the pm_runtime_set_memalloc_noio was added when
del_gendisk is called in this path. Note that the new pm routine
attempts to cycle through all parent devices from the FC target device
to set the memalloc_noio flag. Because of this new change, a dependency
was created between the FC target device and the parent netdev device
in the destroy path.
In order to synchronized the destroy paths, bnx2fc has been modified
to flush all destroy workqueues in the NETDEV_UNREGISTER return path.
[ 4.123584] BUG: soft lockup - CPU#8 stuck for 22s! [kworker/8:3:8082]
[ 4.123713] Call Trace:
[ 4.123719] [<ffffffff815dfbe0>] klist_next+0x20/0xf0
[ 4.123725] [<ffffffff813e9220>] ? pm_save_wakeup_count+0x70/0x70
[ 4.123731] [<ffffffff813d9e4e>] device_for_each_child+0x4e/0x70
[ 4.123735] [<ffffffff813e9554>] pm_runtime_set_memalloc_noio+0x94/0xf0
[ 4.123740] [<ffffffff812d4d74>] del_gendisk+0x264/0x2a0
[ 4.123747] [<ffffffffa00c6dc9>] sd_remove+0x69/0xb0 [sd_mod]
[ 4.123751] [<ffffffff813de24f>] __device_release_driver+0x7f/0xf0
[ 4.123754] [<ffffffff813de2e3>] device_release_driver+0x23/0x30
[ 4.123757] [<ffffffff813ddab4>] bus_remove_device+0xf4/0x170
[ 4.123760] [<ffffffff813da475>] device_del+0x135/0x1d0
[ 4.123765] [<ffffffff81411b75>] __scsi_remove_device+0xc5/0xd0
[ 4.123768] [<ffffffff81411ba6>] scsi_remove_device+0x26/0x40
[ 4.123770] [<ffffffff81411d40>] scsi_remove_target+0x160/0x210
[ 4.123775] [<ffffffffa0420e4c>] fc_rport_final_delete+0xac/0x1f0 [scsi_transport_fc]
[ 4.123780] [<ffffffff810774ab>] process_one_work+0x17b/0x460
[ 4.123783] [<ffffffff8107825b>] worker_thread+0x11b/0x400
[ 4.123786] [<ffffffff81078140>] ? rescuer_thread+0x3e0/0x3e0
[ 4.123791] [<ffffffff8107e9c0>] kthread+0xc0/0xd0
[ 4.123794] [<ffffffff8107e900>] ? kthread_create_on_node+0x110/0x110
[ 4.123798] [<ffffffff8160ceec>] ret_from_fork+0x7c/0xb0
[ 4.123801] [<ffffffff8107e900>] ? kthread_create_on_node+0x110/0x110
Signed-off-by: Eddie Wai <eddie.wai@broadcom.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
pm80xx_get_gsm_dump() was returning "1" in error case
instead of negative error value.
Signed-off-by: Viswas G <Viswas.G@pmcs.com>
Reviewed-by: Jack Wang <jinpu.wang@profitbricks.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Removed redundant code snippets in pm8001_hwi.c and
pm8001_ctl.c
Signed-off-by: Viswas G <Viswas.G@pmcs.com>
Reviewed-by: Jack Wang <jinpu.wang@profitbricks.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
When the reserved memory patches hit -next, several legacy (non-DT) boot
failures were detected and bisected down to that commit. There needs to
be some sanity checking whether a DT is even present before parsing the
reserved ranges.
Reported-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
Tested-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Eric W. Biederman says:
====================
Don't receive packets when the napi budget == 0
After reading through all 120 drivers supporting netpoll I have found 16
more that process at least received packet when the napi budget == 0.
Processing more packets than your budget has always been a bug but
we haven't cared before so it looks like these drivers slipped through,
and need fixes.
As netpoll will shortly be using a budget of 0 to get the tx queue
processing with the rx queue processing we now care.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Processing any incoming packets with a with a napi budget of 0
is incorrect driver behavior.
This matters as netpoll will shortly call drivers with a budget of 0
to avoid receive packet processing happening in hard irq context.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Processing any incoming packets with a with a napi budget of 0
is incorrect driver behavior.
This matters as netpoll will shortly call drivers with a budget of 0
to avoid receive packet processing happening in hard irq context.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Processing any incoming packets with a with a napi budget of 0
is incorrect driver behavior.
This matters as netpoll will shortly call drivers with a budget of 0
to avoid receive packet processing happening in hard irq context.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Processing any incoming packets with a with a napi budget of 0
is incorrect driver behavior.
This matters as netpoll will shortly call drivers with a budget of 0
to avoid receive packet processing happening in hard irq context.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Processing any incoming packets with a with a napi budget of 0
is incorrect driver behavior.
This matters as netpoll will shortly call drivers with a budget of 0
to avoid receive packet processing happening in hard irq context.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Processing any incoming packets with a with a napi budget of 0
is incorrect driver behavior.
This matters as netpoll will shortly call drivers with a budget of 0
to avoid receive packet processing happening in hard irq context.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Processing any incoming packets with a with a napi budget of 0
is incorrect driver behavior.
This matters as netpoll will shortly call drivers with a budget of 0
to avoid receive packet processing happening in hard irq context.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Processing any incoming packets with a with a napi budget of 0
is incorrect driver behavior.
This matters as netpoll will shortly call drivers with a budget of 0
to avoid receive packet processing happening in hard irq context.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Processing any incoming packets with a with a napi budget of 0
is incorrect driver behavior.
This matters as netpoll will shortly call drivers with a budget of 0
to avoid receive packet processing happening in hard irq context.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Processing any incoming packets with a with a napi budget of 0
is incorrect driver behavior.
This matters as netpoll will shortly call drivers with a budget of 0
to avoid receive packet processing happening in hard irq context.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Processing any incoming packets with a with a napi budget of 0
is incorrect driver behavior.
This matters as netpoll will shortly call drivers with a budget of 0
to avoid receive packet processing happening in hard irq context.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Processing any incoming packets with a with a napi budget of 0
is incorrect driver behavior.
This matters as netpoll will shortly call drivers with a budget of 0
to avoid receive packet processing happening in hard irq context.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Processing any incoming packets with a with a napi budget of 0
is incorrect driver behavior.
This matters as netpoll will shortly call drivers with a budget of 0
to avoid receive packet processing happening in hard irq context.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Processing any incoming packets with a with a napi budget of 0
is incorrect driver behavior.
This matters as netpoll will shortly call drivers with a budget of 0
to avoid receive packet processing happening in hard irq context.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Processing any incoming packets with a with a napi budget of 0
is incorrect driver behavior.
This matters as netpoll will shortly call drivers with a budget of 0
to avoid receive packet processing happening in hard irq context.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Processing any incoming packets with a with a napi budget of 0
is incorrect driver behavior.
This matters as netpoll will shortly call drivers with a budget of 0
to avoid receive packet processing happening in hard irq context.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
John W. Linville says:
====================
Please pull these last(?) few wireless bits intended for the 3.14
stream. Each is here to address a problem found with a patch already
merged...
Dave Jones gives us a memory leak fix, for an error path in brcmfmac.
Felix Fietkau moves a small delay to make it actually reachable.
Helmut Schaa fixes an ath9k sequence numbering problem for non-data
frames.
Stanislaw Gruszka reverts an earlier fix that was found to cause
random connection drops on RT5390 PCI adapters
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Hariprasad Shenai says:
====================
Doorbell drop Avoidance Bug fix for iw_cxgb4
This patch series provides fixes for Chelsio T4/T5 adapters
related to DB Drop avoidance and other small fix related to keepalive on
iw-cxgb4.
The patches series is created against David Miller's 'net-next' tree.
And includes patches on cxgb4 and iw_cxgb4 driver.
We would like to request this patch series to get merged via David Miller's
'net-next' tree.
We have included all the maintainers of respective drivers. Kindly review the
change and let us know in case of any review comments.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
