- 19 Dec, 2013 35 commits
-
-
Saurav Kashyap authored
Signed-off-by:
Giridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by:
Saurav Kashyap <saurav.kashyap@qlogic.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
Geert Uytterhoeven authored
do_div() is meant for divisions of 64-bit number by 32-bit numbers. Passing 64-bit divisor types caused issues in the past on 32-bit platforms, cfr. commit ea077b1b ("m68k: Truncate base in do_div()"). As scsi_device.sector_size is unsigned (int), factor should be unsigned int, too. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Felipe Pena authored
On lpfc_debugfs_initialize function the dumpHostSlim member setup happens when 'phba->sli_rev < LPFC_SLI_REV4' is true, however when it is false NULL has been assigned to debug_dumpHBASlim instead of debug_dumpHostSlim. Signed-off-by:
Felipe Pena <felipensp@gmail.com> Acked-by:
James Smart <james.smart@emulex.com> Signed-off-by:
-
Ben Collins authored
The assumption that sizeof(long) >= sizeof(resource_size_t) can lead to truncation of the PCI resource address, meaning this driver didn't work on 32-bit systems with 64-bit PCI adressing ranges. Signed-off-by:
Ben Collins <ben.c@servergy.com> Acked-by:
Sumit Saxena <sumit.saxena@lsi.com> Signed-off-by:
-
Hannes Reinecke authored
The documentation has gone out-of-sync, so update it to the current status. Signed-off-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
-
Ren Mingxin authored
The former minimum valid value of 'eh_deadline' is 1s, which means the earliest occasion to shorten EH is 1 second later since a command is failed or timed out. But if we want to skip EH steps ASAP, we have to wait until the first EH step is finished. If the duration of the first EH step is long, this waiting time is excruciating. So, it is necessary to accept 0 as the minimum valid value for 'eh_deadline'. According to my test, with Hannes' patchset 'New EH command timeout handler' as well, the minimum IO time is improved from 73s (eh_deadline = 1) to 43s(eh_deadline = 0) when commands are timed out by disabling RSCN and target port. Signed-off-by:
Ren Mingxin <renmx@cn.fujitsu.com> Signed-off-by:
-
Hannes Reinecke authored
32bit accesses are guaranteed to be atomic, so we can remove the spinlock when checking for eh_deadline. We only need to make sure to catch any updates which might happened during the call to time_before(); if so we just recheck with the correct value. Signed-off-by:
-
Hannes Reinecke authored
When a command runs into a timeout we need to send an 'ABORT TASK' TMF. This is typically done by the 'eh_abort_handler' LLDD callback. Conceptually, however, this function is a normal SCSI command, so there is no need to enter the error handler. This patch implements a new scsi_abort_command() function which invokes an asynchronous function scsi_eh_abort_handler() to abort the commands via the usual 'eh_abort_handler'. If abort succeeds the command is either retried or terminated, depending on the number of allowed retries. However, 'eh_eflags' records the abort, so if the retry would fail again the command is pushed onto the error handler without trying to abort it (again); it'll be cleared up from SCSI EH. [hare: smatch detected stray switch fixed] Signed-off-by:
-
James Bottomley authored
Commit 18a4d0a2 (Handle disk devices which can not process medium access commands) was introduced to offline any device which cannot process medium access commands. However, commit 3eef6257 (Reduce error recovery time by reducing use of TURs) reduced the number of TURs by sending it only on the first failing command, which might or might not be a medium access command. So in combination this results in an erratic device offlining during EH; if the command where the TUR was sent upon happens to be a medium access command the device will be set offline, if not everything proceeds as normal. This patch moves the check to the final test, eliminating this problem. Signed-off-by:
-
Paul Gortmaker authored
After getting warnings in an allyesconfig build[1] from this driver, I decided to remind myself just how old it was, and whether it warranted fixing. In the Kconfig help text, I found: "This driver will eventually be phased out entirely" Going back to the history archive, I see the line was added[2] in Feb 2002, when we moved from v2.4.2.1 ---> v2.4.2.2 So, with over a decade of notification, and multiple major releases since then, I think we can justify removing this. Currently we have people wasting time building it during routine testing, and then wasting more time re-researching the known reported warnings, only to find that nobody really is willing to integrate the fixes[3] for it. A quick search didn't seem to indicate any active user base for it. If someone happens to have a quirky _old_ card that the eleven year old "new" driver doesn't work with, then it is entirely reasonable that they stick with a kernel version that predates this removal. [1] drivers/scsi/aic7xxx_old.c: In function ‘aic7xxx_register’: drivers/scsi/aic7xxx_old.c:7901:5: warning: case value ‘257’ not in enumerated type ‘ahc_chip’ [-Wswitch] drivers/scsi/aic7xxx_old.c:7898:5: warning: case value ‘513’ not in enumerated type ‘ahc_chip’ [-Wswitch] drivers/scsi/aic7xxx_old.c: In function ‘aic7xxx_load_seeprom’: drivers/scsi/aic7xxx_old.c:8517:5: warning: case value ‘257’ not in enumerated type ‘ahc_chip’ [-Wswitch] drivers/scsi/aic7xxx_old.c:8510:5: warning: case value ‘513’ not in enumerated type ‘ahc_chip’ [-Wswitch] [2] http://git.kernel.org/cgit/linux/kernel/git/tglx/history.git commit 44e8778c [3] https://lkml.org/lkml/2012/10/29/215Signed-off-by:Paul Gortmaker <paul.gortmaker@windriver.com> Acked-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Douglas Gilbert authored
update sg MAINTAINERS file entry: web site and documentation entry Signed-off-by:
Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
-
Saurav Kashyap authored
Signed-off-by:
-
Saurav Kashyap authored
Signed-off-by:
-
Armen Baloyan authored
Signed-off-by:
Armen Baloyan <armen.baloyan@qlogic.com> Signed-off-by:
-
Sawan Chandak authored
Signed-off-by:
Sawan Chandak <sawan.chandak@qlogic.com> Signed-off-by:
-
Chad Dupuis authored
Signed-off-by:
Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by:
-
Sawan Chandak authored
Signed-off-by:
-
Chad Dupuis authored
Signed-off-by:
-
Armen Baloyan authored
[SCSI] qla2xxx: Add changes to obtain ISPFX00 adapters product information in accordance with firmware update. Signed-off-by:
-
Armen Baloyan authored
Signed-off-by:
-
Atul Deshmukh authored
Signed-off-by:
Atul Deshmukh <atul.deshmukh@qlogic.com> Signed-off-by:
-
Joe Carnuccio authored
Signed-off-by:
Joe Carnuccio <joe.carnuccio@qlogic.com> Signed-off-by:
-
Joe Carnuccio authored
Signed-off-by:
-
Armen Baloyan authored
Signed-off-by:
-
Chad Dupuis authored
If we become disconnected from the PCI bus/PCIe fabric, there can be long delays in register reads which can cause erroneous decisions to be made and cause a soft lockup if a lock is held too long. As a preventative measure, check for a disconnection (register reads that return -1) and then disable the board if we find ourselves in this condition. For now, check in our interrupt handlers and the per adapter one second timer. Signed-off-by:
-
Chad Dupuis authored
Signed-off-by:
-
Chad Dupuis authored
[SCSI] Revert "qla2xxx: Ramp down queue depth for attached SCSI devices when driver resources are low." This reverts commit 3c290d0bSigned-off-by:
-
Saurav Kashyap authored
[SCSI] qla2xxx: Don't consider the drivers knocked out of IDC participation for future reset recovery process. Signed-off-by:
-
Chad Dupuis authored
Signed-off-by:
-
Joe Carnuccio authored
Signed-off-by:
-
Sawan Chandak authored
Signed-off-by:
-
Chad Dupuis authored
If the execute firmware command fails we do not stop the rest of the initialization process which will continue to fail so if we encounter an error simply short circuit the process. Signed-off-by:
-
Armen Baloyan authored
Signed-off-by:
-
Stephen M. Cameron authored
If a fifo full condition is encountered, i/o requests will stack up in the h->reqQ queue. The only thing which empties this queue is start_io, which only gets called when new i/o requests come in. If none are forthcoming, i/o in h->reqQ will be stalled. To fix this, whenever fifo full condition is encountered, this is recorded, and the interrupt handler examines this to see if a fifo full condition was recently encountered when a command completes and will call start_io to prevent i/o's in h->reqQ from getting stuck. I've only ever seen this problem occur when running specialized test programs that pound on the the CCISS_PASSTHRU ioctl. Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
-
Stephen M. Cameron authored
Cap CCISS_BIG_PASSTHRU as well. If an attempt is made to exceed this, ioctl() will return -1 with errno == EAGAIN. This is to prevent a userland program from exhausting all of pci_alloc_consistent memory. I've only seen this problem when running a special test program designed to provoke it. 20 concurrent commands via the passthru ioctls (not counting SG_IO) should be more than enough. Signed-off-by:
-
- 16 Dec, 2013 5 commits
-
-
Stephen M. Cameron authored
Signed-off-by:
Scott Teel <scott.teel@hp.com> Acked-by:
-
Stephen M. Cameron authored
We were leaking a command buffer if a DMA mapping error was encountered in the CCISS_BIG_PASSTHRU ioctl. Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
The hardware guys tell us that after initiating a software reset via the doorbell register we need to wait 5 seconds before attempting to talk to the board *at all*. This means that we cannot watch the board to verify it transitions from "ready" to to "not ready" then back "ready", since this transition will most likely happen during those 5 seconds (though we can still verify the reset happens by watching the "driver version" field get cleared.) Signed-off-by:
-
Stephen M. Cameron authored
There's no point in trying since it can't work, and if you do try, it will just hang the system on shutdown. Signed-off-by:
-
