On Thursday 15 November 2007 17:42:30 Randy Dunlap wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> - Change title to remove "Mid-Layer" since the doc is about all of the
> SCSI layers.
> - Use "SCSI" instead of "scsi" in docbook text.
> - Use "*/" to end kernel-doc notation blocks.
> - A few ot
From: Randy Dunlap <[EMAIL PROTECTED]>
Use correct function name in kernel-doc.
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_devinfo.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- scsi-misc-26.orig/drivers/scsi/scsi_devinfo.c
+++ scsi-misc-26/drivers/scs
From: Randy Dunlap <[EMAIL PROTECTED]>
- Change title to remove "Mid-Layer" since the doc is about all of the
SCSI layers.
- Use "SCSI" instead of "scsi" in docbook text.
- Use "*/" to end kernel-doc notation blocks.
- A few other minor typo fixes.
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
On Thu, 2007-11-15 at 15:35 -0700, Moore, Eric wrote:
> > No. When the command goes via SG_IO it bypasses all return status
> > processing (and QUEUE_FULL/BUSY is a return status). When it's
> > submitted in the normal way (i.e. via a ULD) then the mid-layer
> > processes these returns to a retry
On Thu, 2007-11-15 at 15:59 -0600, Chris Friesen wrote:
> Moore, Eric wrote:
> > On Thursday, November 15, 2007 12:10 PM, Chris Friesen wrote:
>
> >>Does this status mean that the command needs to be retried by the
> >>userspace app, that it has already been retried by the lower
> >>levels and
> No. When the command goes via SG_IO it bypasses all return status
> processing (and QUEUE_FULL/BUSY is a return status). When it's
> submitted in the normal way (i.e. via a ULD) then the mid-layer
> processes these returns to a retry strategy.
>
James - Today I'm working some other customer i
Moore, Eric wrote:
On Thursday, November 15, 2007 12:10 PM, Chris Friesen wrote:
Does this status mean that the command needs to be retried by the
userspace app, that it has already been retried by the lower
levels and
is now completed, or something else entirely?
The midlayer is retrying
On Thu, 2007-11-15 at 16:27 -0500, Douglas Gilbert wrote:
> That code was there when I inherited the sg driver in 1998
> (the original sg drivers dates from around 1993). The reason
> is/was that the DMA element of some HBA needed it. I tried
> to take it out once (probably in the last millenium)
Boaz Harrosh wrote:
> On Thu, Nov 15 2007 at 19:15 +0200, Matthew Dharm <[EMAIL PROTECTED]> wrote:
>> On Wed, Nov 14, 2007 at 10:23:09AM +0100, Gabriel C wrote:
>>> Matthew Dharm wrote:
On Wed, Nov 14, 2007 at 06:33:39AM +0100, Gabriel C wrote:
> Matthew Dharm wrote:
>> On Tue, Nov 13,
Igor A. Nesterov wrote:
> dxfer_len value provided to SG_IO ioctl as a part of sg_io_hdr_t
> structure is rounded up to the nearest 512 bytes boundary just before
> scatterlist allocation in sg_build_indirect()
>
> /* round request up to next highest SG_SECTOR_SZ byte boundary */
> blk_s
Greetings all,
It is my great pleasure to announce that the Linux-iSCSI.org project has
reached its first 2.9-BETA release and its now offering the ability to
build source against any RPM or DEB based kernel and distribution. The
Linux-iSCSI.org West cluster is offering binaries for CentOS 5 and
This patch was not tested.
--
SR_REQ is defined 0x20, but bitanding has no effect because '!' has a higher
priority than '&'
Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
---
diff --git a/drivers/scsi/atari_NCR5380.c b/drivers/scsi/atari_NCR5380.c
index 03dbe60..5696588 100644
--- a/drivers/scsi/a
On Thursday, November 15, 2007 12:44 PM, James Smart wrote:
> The midlayer doesn't do this automatically. The LLDD has to note the
> QUEUE_FULL/TASK_SET_FULL status, then call scsi_adjust_queue_depth()
> to manipulate things. And this gets really hairy to decrease
> load, then
> ramp back up.
>
On Thursday, November 15, 2007 12:10 PM, Chris Friesen wrote:
>
> My impression is that the per-device queue is supposed to be
> decreased
> at runtime to match the actual size that the hardware can handle. In
> the earlier version we're seeing the queue set to 7 at runtime, while
> the more
James Bottomley wrote:
> On Thu, 2007-11-15 at 11:38 -0500, Tony Battersby wrote:
>
>> James Bottomley wrote:
>>
>>> On Thu, 2007-11-15 at 10:06 -0500, Tony Battersby wrote:
>>>
>>>
This patch increases the sg_tablesize for sym53c8xx from 96 to 128,
which enables command
Moore, Eric wrote:
You already figured out the problem, I don't understand why your asking
if the kernel verison is behaving properly. You said between those
driver versions the device queue depth increased from 32 to 64, and that
is exactly what happened. The reason for the increase is some
Chris Friesen wrote:
Moore, Eric wrote:
You already figured out the problem, I don't understand why your asking
if the kernel verison is behaving properly. You said between those
driver versions the device queue depth increased from 32 to 64, and that
is exactly what happened. The reason
On Thu, 2007-11-15 at 10:06 -0500, Tony Battersby wrote:
> This patch increases the sg_tablesize for sym53c8xx from 96 to 128,
> which enables commands to transfer larger amounts of data (e.g. 512 KB
> instead of 384 KB, assuming 4 KB non-adjacent pages).
>
> In the current design of sym53c8xx, SY
James Bottomley wrote:
> On Thu, 2007-11-15 at 10:06 -0500, Tony Battersby wrote:
>
>> This patch increases the sg_tablesize for sym53c8xx from 96 to 128,
>> which enables commands to transfer larger amounts of data (e.g. 512 KB
>> instead of 384 KB, assuming 4 KB non-adjacent pages).
>>
>> In t
On Thu, 2007-11-15 at 11:38 -0500, Tony Battersby wrote:
> James Bottomley wrote:
> > On Thu, 2007-11-15 at 10:06 -0500, Tony Battersby wrote:
> >
> >> This patch increases the sg_tablesize for sym53c8xx from 96 to 128,
> >> which enables commands to transfer larger amounts of data (e.g. 512 KB
dxfer_len value provided to SG_IO ioctl as a part of sg_io_hdr_t
structure is rounded up to the nearest 512 bytes boundary just before
scatterlist allocation in sg_build_indirect()
/* round request up to next highest SG_SECTOR_SZ byte boundary */
blk_size = (blk_size + SG_SECTOR_MSK) & (
This patch increases the sg_tablesize for sym53c8xx from 96 to 128,
which enables commands to transfer larger amounts of data (e.g. 512 KB
instead of 384 KB, assuming 4 KB non-adjacent pages).
In the current design of sym53c8xx, SYM_CONF_MAX_SG must be set low
enough so that (sym_fw1.a_size <= PAG
Calling zfcp_erp_strategy_check_action() after zfcp_erp_action_to_running()
in zfcp_erp_strategy() might cause an unbalanced up() for erp_ready_sem,
which makes the zfcp recovery fail somewhere along the way:
erp thread processing erp_action:
|
| someone waking up erp thread for erp_action
zfcp_erp_action_dismiss() used to ignore any actions in the ready list. This
is a bug. Any action superseded by a stronger action needs to be dismissed.
This patch changes zfcp_erp_action_dismiss() so that it dismisses actions
regardless of their list affiliation. The ERP thread is able to handle t
I am posting 2 bug fixes which are required for the zfcp error recovery
to work correctly. It takes some error injection tests to strain the
zfcp error recovery to the extend which triggers both bugs. The bugs are
related to recovery actions which need to be dismissed because some
stronger action h
All of our machines with QLogics ISP1020 cards seem to have lost them on
boot with 2.6.24-rc1-mm1+hotfixes.
# lspci
:00:0a.0 SCSI storage controller: QLogic Corp. ISP1020 Fast-wide
SCSI (rev 05)
# lspci -n
:00:0a.0 0100: 1077:1020 (rev 05)
# lspci -v -v
:00:0a.0 SCSI storage controll
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix scsi_tgt_lib build when dprintk is defined:
Also fix accessors problem when dprintk is defined
drivers/scsi/scsi_tgt_lib.c: In function 'scsi_tgt_cmd_destroy':
drivers/scsi/scsi_tgt_lib.c:183: warning: format '%lu' expects type 'long
unsigned int', but
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix scsi_tgt_lib build when dprintk is defined:
drivers/scsi/scsi_tgt_lib.c: In function 'scsi_tgt_cmd_destroy':
drivers/scsi/scsi_tgt_lib.c:183: warning: format '%lu' expects type 'long
unsigned int', but argument 6 has type 'unsigned int'
drivers/scsi/scs
Hi,
not sure if this list is the right way to look for help - but lets give it a
try ;-).
I am running openSuSE with Kernel 2.6.22.12-0.1-xen #1 SMP 2007/11/06 23:05:18
UTC x86_64 x86_64 x86_64 GNU/Linux.
The RAID Controller I am using is Adaptec 2400A with four 400GB HDDs as RAID5.
In the pa
Some hardware handler have a need to identify the controller
handling the paths, as the controller might only be able to
process one path-switching command in a row.
This patch implements a framework for selecting controllers
and allows for throttling (single-threading) commands to
this controller
Some hardware handler might prefer to queue the commands to
the controller so as not to flood the controller with commands.
This patch implements a generic workqueue framework for
hardware handler and converts dm-mpath-rdac to use it.
Signed-off-by: Hannes Reinecke <[EMAIL PROTECTED]>
---
driver
This adds a new SPC-3 ALUA hardware handler for multipathing.
Signed-off-by: Hannes Reinecke <[EMAIL PROTECTED]>
---
drivers/md/Kconfig |7 +
drivers/md/Makefile|2 +
drivers/md/dm-mpath-alua.c | 681
include/scsi/scsi.h
Hi all,
this patchset adds some more abstraction to the multipath
hardware handlers.
- A generic workqueue framework is added, which allows the
hardware handler to submit failover commands independent
from multipath I/O.
- The exsting RDAC hardware handler is converted to use that
framework
James Smart <[EMAIL PROTECTED]> wrote:
> I've added the dm reflector to this email...
>
> >Best would to have DM-multipath handle the disconnects gracefully, of
> >course. But since it doesn't appear to be happening anytime soon: A
> >workaround provided by the transport layer would be very welc
34 matches
Mail list logo
