For the start of this thread please refer to:
http://marc.theaimsgroup.com/?l=linux-kernel&m=111327337005048&w=2
and
http://marc.theaimsgroup.com/?l=linux-kernel&m=111328256211837&w=2
Regards,
The combined open-iscsi and linux-iscsi teams
SCSI LLDD, the 2nd part:
- iscsi_i
On Mon, Apr 11, 2005 at 10:36:51PM -0700, Greg KH wrote:
> On Mon, Apr 11, 2005 at 08:24:08PM -0700, Alex Aizman wrote:
> > Common header files:
> > - iscsi_ifev.h (user/kernel events).
>
> These structures cross the user/kernel boundry? If so, they _must_ use
> the __
On Tue, Apr 12, 2005 at 08:27:33AM +0100, Christoph Hellwig wrote:
> On Mon, Apr 11, 2005 at 10:36:51PM -0700, Greg KH wrote:
> > On Mon, Apr 11, 2005 at 08:24:08PM -0700, Alex Aizman wrote:
> > > Common header files:
> > > - iscsi_ifev.h (user/kernel events).
> >
> > T
On Tue, Apr 12, 2005 at 12:45:14AM -0700, Greg KH wrote:
> Um, why? We've been down this road before, and for types that cross the
> boundry, we _must_ use the __ version of the kernel types, not the
> uint32_t stuff.
That's total bullshit. C99 types just work in both the kernel and userland,
wh
Guys, could you please take a look at this one, help move it forward a bit?
It's a 460k patch, so...
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/broken-out/areca-raid-linux-scsi-driver.patch
thanks.
-
To unsubscribe from this list: send the line "unsu
03_scsi_reqfn_reimplementation.patch
This patch rewrites scsi_request_fn(). scsi_dispatch_cmd() is
merged into scsi_request_fn(). Goals are
* Remove unnecessary operations (host_lock unlocking/locking,
recursing into scsi_run_queue(), ...)
* Consolidate
Oops, I forgot to mention that reqfn is reformatted mostly as
suggested by Chritoph Hellwig. Sorry.
On Tue, Apr 12, 2005 at 07:33:03PM +0900, Tejun Heo wrote:
> 03_scsi_reqfn_reimplementation.patch
>
> This patch rewrites scsi_request_fn(). scsi_dispatch_cmd() is
> merged into scsi
03_scsi_requeue_use_scsi_retry_command_instead_of_scsi_queue_insert.patch
There are two users of scsi_queue_insert() left now. One in
scsi_softirq() and the other in scsi_eh_flush_done_q(). The
only additional functionality of scsi_queue_insert() used is
setting d
05_scsi_requeue_move_init_cmd_errh.patch
As now all non-reprepped requeue goes through
scsi_retry_command() which clears sense buffer, there's no
need to call scsi_init_cmd_errh() in scsi_request_fn(). Move
scsi_init_cmd_errh() to scsi_prep_fn().
Signed-off-by: Te
Hello again, guys.
This is the last patchset and assumes that all previous patchsets are
applied. This patchset conolidates requeue paths such that all
requeue after command issue goes through scsi_requeue_command().
Requeueing due to unifinished bytes goes through
scsi_requeue_command_reprep()
01_scsi_requeue_make_requeue_command_public.patch
This patch makes the following changes to
scsi_requeue_command() and make the function public.
* remove redundant argument @q
* remove REQ_DONTPREP clearing
* add state/owner setting
A new inline fu
02_scsi_requeue_use_scsi_requeue_command_in_scsi_retry_command.patch
scsi_retry_command() orignally used scsi_queue_insert() for
requeueing. This patch makes it use scsi_retry_command()
instead. Adding a call to scsi_device_unbusy() is sufficient
and the change al
04_scsi_requeue_remove_scsi_queue_insert.patch
scsi_queue_insert() now has no user left. Kill it.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
scsi_lib.c | 76
scsi_priv.h |1
2 files changed, 77 deletions(-)
Index:
06_scsi_requeue_reset_result.patch
cmd->result wasn't cleared on requeue or reprep. Clear it.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
scsi.c |9 +
scsi_lib.c |1 +
2 files changed, 6 insertions(+), 4 deletions(-)
Index: scsi-reqfn-export/drivers/scsi/scsi.c
==
07_scsi_requeue_consolidate_setup_cmd_retry_calls_in_eh.patch
scsi_setup_cmd_retry() is needed because scsi eh may alter
scsi_cmnd to issue eh commands. Consolidate calls to
scsi_setup_cmd_retry() to one place in scsi_eh_flush_done_q().
This change makes scsi_retry
Dailey, Nate wrote:
This is my first attempt at submitting a patch, so I hope I'm not making any
mistakes...
This patch fixes two problems I came across in sg, both of which occur when
sg_remove is called on a disk which hasn't yet been sg_release'd:
1. I got the following Oops in sg_remove:
--
Una
We have a DID_IMM_RETRY to require a retry at once, but we could do with
a DID_REQUEUE to instruct the mid-layer to treat this command in the
same manner as QUEUE_FULL or BUSY (i.e. halt the submission until
another command returns ... or the queue pressure builds if there are no
outstanding comman
Tejun Heo wrote:
Hello, guys.
This patchset reimplements scsi_request_fn(). All prep's are moved
into prep_fn and all state checking/issueing are moved into
scsi_reqfn. prep_fn() only terminates/defers unpreparable requests
and all requests are terminated through scsi midlayer.
This patchset a
Hello, Christoph Hellwig.
On Mon, Apr 11, 2005 at 01:44:19PM +0100, Christoph Hellwig wrote:
> > + cmd->request->flags |= REQ_SOFTBARRIER;
> > +
> > + spin_lock_irqsave(q->queue_lock, flags);
> > + blk_requeue_request(q, cmd->request);
> > + spin_unlock_irqrestore(q->queue_lock, flags);
>
On Tue, 2005-04-05 at 14:30 -0600, Moore, Eric Dean wrote:
> Ok fine - This fix is already there in the series of patches
> I provided a week ago for splitting the mpt fusion drivers
> into seperate bus type drivers.
>
> James any word on whether those series of patches will get
> approved?
The p
On Mon, 2005-04-11 at 22:35 -0700, Greg KH wrote:
> On Mon, Apr 11, 2005 at 08:24:08PM -0700, Alex Aizman wrote:
> > +typedef uint64_t iscsi_snx_t; /* iSCSI Data-Path session
> > handle */
> > +typedef uint64_t iscsi_cnx_t; /* iSCSI Data-Path connection
> > handle */
>
01_scsi_reqfn_consolidate_error_handling.patch
This patch fixes a queue stall bug which occurred when sgtable
allocation failed and device_busy == 0. When scsi_init_io()
returns BLKPREP_DEFER or BLKPREP_KILL, it's supposed to free
resources itself. This patch cons
02_scsi_reqfn_move_preps_to_prep_fn.patch
Move request preparations scattered in scsi_request_fn() and
scsi_dispatch_cmd() into scsi_prep_fn()
* CDB_SIZE check in scsi_dispatch_cmd()
* SCSI-2 LUN preparation in scsi_dispatch_cmd()
No invalid request reache
04_scsi_reqfn_remove_wait_req_end_io.patch
As all requests are now terminated via scsi midlayer, we don't
need to set end_io for special reqs, remove it.
Note that scsi_kill_requests() still terminates requests using
blk layer. The path is circular-ref workaround
Hi,
Am I right in the assumption that scsi_cmnd->resid is just of use for
requests initiated by sg?
How does the SCSI-stack handle normal (non-sg) requests for SCSI disks
for which a scsi_cmnd->resid is set? AFAIK, resid is ignored by
sd. So, such requests are returned to the block layer althoug
Hello, guys.
This patchset reimplements scsi_request_fn(). All prep's are moved
into prep_fn and all state checking/issueing are moved into
scsi_reqfn. prep_fn() only terminates/defers unpreparable requests
and all requests are terminated through scsi midlayer.
[ Start of patch descriptions
From: Jason Gaston <[EMAIL PROTECTED]>
This patch adds the Intel ESB2 DID's to the ahci.c file for AHCI mode SATA
support.
Signed-off-by: Jason Gaston <[EMAIL PROTECTED]>
Cc:
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/drivers/scsi/ahci.c |6 ++
1 files changed, 6 ins
On Tue, Apr 12, 2005 at 03:31:34AM -0700, [EMAIL PROTECTED] wrote:
>
> From: Jason Gaston <[EMAIL PROTECTED]>
>
> This patch adds the Intel ESB2 DID's to the ahci.c file for AHCI mode SATA
> support.
Please don't send libata stuff directly to Linus.
Even a patch that appears as simple as this h
Andreas Herrmann wrote:
Hi,
Am I right in the assumption that scsi_cmnd->resid is just of use for
requests initiated by sg?
How does the SCSI-stack handle normal (non-sg) requests for SCSI disks
for which a scsi_cmnd->resid is set? AFAIK, resid is ignored by
sd. So, such requests are returned to t
Re: Va11ium Ci-alis Vi-agra
http://ofkvetkgf6lrhs7o78z6ea7o.bhwittalii.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
30 matches
Mail list logo
