On Mon, Jan 28, 2008 at 06:29:12PM +0900, FUJITA Tomonori wrote:
> > ACK for fixing the access to the sense buffer.
> >
> > We are working internally on cleaning up the zfcp messages. With this
> > change, the 'trace' and 'hex dump' messages will disappear. So, could
> > you simply remove the ZFCP
On Sun, Jan 27, 2008 at 12:41:50PM +0900, FUJITA Tomonori wrote:
> The commit de25deb18016f66dcdede165d07654559bb332bc changed
> scsi_cmnd.sense_buffer from a static array to a dynamically allocated
> buffer. We can't access to sense_buffer in '&cmd->sense_buffer' way.
>
> Signed-off-by: FUJITA To
On Tue, Jan 08, 2008 at 10:46:51AM -0500, James Smart wrote:
> Christoph Hellwig wrote:
> >On Tue, Jan 08, 2008 at 09:09:36AM +0100, Christof Schmitt wrote:
> >>zfcp has a couple of definitions to describe the FC protocol. Grepping
> >>through the complete source tr
zfcp has a couple of definitions to describe the FC protocol. Grepping
through the complete source tree shows that e.g. the lpfc module makes
similar private definitions. It think that it would make sense to
introduce a global header file for FC related definitions that each FC
driver can use.
The
: Swen Schillig <[EMAIL PROTECTED]>
Signed-off-by: Christof Schmitt <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_aux.c |2
drivers/s390/scsi/zfcp_def.h | 14 +++
drivers/s390/scsi/zfcp_fsf.c | 36 +
drivers/s390/scsi/zfcp_fsf.h | 29 ++-
drivers/s390/scsi/
looking attributes for the FC host
refer to the adapter. Since the FCP adapter can be shared across
multiple Linux systems, the two groups of attributes have a different
scope.
--
Christof Schmitt
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a
From: Christof Schmitt <[EMAIL PROTECTED]>
Since the SCSI layer uses the request queues from the block layer, blktrace can
also be used to trace the requests to all SCSI devices (like SCSI tape drives),
not only disks. The only missing part is the ioctl interface to start and stop
tracing.
There was no response on this patch last time, so i am resubmitting it here. It
applies on the current linux-2.6 git tree.
--
Christof Schmitt
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo inf
From: Christof Schmitt <[EMAIL PROTECTED]>
We need to hold the queue-lock when checking whether we still have a valid
unit/port handle for the task management command, i.e whether we can issue this
request for this unit/port. If the error recovery is about to close this
unit/port, t
From: Christof Schmitt <[EMAIL PROTECTED]>
We need to hold the queue-lock when checking whether we still have a valid
unit/port handle for the abort command, i.e whether we can issue this request
for this unit/port. If the error recovery is about to close this unit/port,
then it competes f
From: Christof Schmitt <[EMAIL PROTECTED]>
We need to hold the queue-lock when checking whether we still have a valid
unit/port handle for the FCP command, i.e whether we can issue this request for
this unit/port. If the error recovery is about to close this unit/port, then it
competes f
From: Christof Schmitt <[EMAIL PROTECTED]>
We need to hold the queue-lock when checking whether we still have a valid port
handle for the ELS command, i.e whether we can issue this request for this
port. If the error recovery is about to close this port, then it competes for
the queue-lo
lt;[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
Signed-off-by: Christof Schmitt <[EMAIL PROTECTED]>
Signed-off-by: Martin Peschke <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_def.h | 14 ++
drivers/s390/scsi/zfcp_erp.c |3 ++-
2 file
From: Christof Schmitt <[EMAIL PROTECTED]>
According to the FSF spec, word 0 (bytes 0-3) has the handle
specified with the abort command and word 1 (bytes 4-7) has the
handle for the command to be aborted. Fix the if statements
that try to compare those.
Signed-off-by: Christof Schmitt &
James,
here are some zfcp fixes. They apply on the current version of scsi-misc.
Regards,
Christof Schmitt
-
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
TEARDOWN ioctls from
blktrace to the sg device files. With this change, blktrace can be
used for SCSI devices like for disks, e.g.:
blktrace -d /dev/sg1 -o - | blkparse -i -
Signed-off-by: Christof Schmitt <[EMAIL PROTECTED]>
---
block/blktrace.c | 24 ++--
e(0)
> > +#define blk_trace_remove(q) do { } while(0)
> > +#endif
> > +
>
> Put these in the blktrace include file.
Thanks for your input. I will prepare and send an updated version of
the patch. I also want to do some more testing, especially to see how
i can get the si
, e.g.:
# blktrace -d /dev/sg1 -o - | blkparse -i -
I am seeking input in this approach: Is this approach worth pursuing
to enable blktrace to trace SCSI tape drives? Would there be a better
approach to get this trace data?
Christof Schmitt
---
block/blktrace.c | 19
From: Christof Schmitt <[EMAIL PROTECTED]>
Introduce a flag that allows the SCSI low level device driver to
disable the automatic scanning for LUNs from the FC transport class.
This is for the zfcp device driver that manages the attached units on
its own and does not want to have the aut
On Tue, Aug 21, 2007 at 09:46:34AM -0600, Matthew Wilcox wrote:
> The comment exceeds 80 columns. Why have a comment at all, none of the
> other fields here do, and it doesn't seem to add anything to me.
Agree. I will remove the comment.
-
To unsubscribe from this list: send the line "unsubscribe
From: Christof Schmitt <[EMAIL PROTECTED]>
Introduce a flag that allows the SCSI low level device driver to
disable the automatic scanning for LUNs from the FC transport class.
This is for the zfcp device driver that manages the attached units on
its own and does not want to have the aut
On Tue, Aug 21, 2007 at 09:03:17AM -0400, James Smart wrote:
> Nit (but preferred) : change "no_target_scan" to "disable_target_scan".
> Otherwise, patch is good.
Ok. I will send the fixed version in a separate mail.
> Yep. However, I don't agree with Hannes in this case. Given that the
> firm
ue it for zfcp, if he does anyway he will simply get
the warning message.
Christof Schmitt
---
drivers/scsi/scsi_transport_fc.c |4 +++-
include/scsi/scsi_transport_fc.h |3 +++
2 files changed, 6 insertions(+), 1 deletion(-)
--- linux-2.6.orig/drivers/scsi/scsi_transport_fc.c
+++ l
ould
be an additional flag in the FC transport template.
What do others think? If there is an agreement, i will followup with a
new patch.
This can go away, as soon as zfcp does not have to support the
non-NPIV adapter sharing anymore, but this won't happen in the
foreseeable future.
Christof Schmitt
rted as FCP LUN 40F04000.
When the SCSI midlayer uses and exports this value in sysfs, it should
be displayed in the same format (hex).
I don't know if the multi level scheme is actually used as hierarchy
somewhere. If somebody would be interested in using this information,
i think a usersp
he pairs to get the real FCP LUN (0x401040c3) is too much.
Are there any plans to improve this? Showing the LUN in sysfs as hex
number would be the first step. Or does it make more sense to keep the
decimal number in sysfs and let tools like lsscsi do the conversion?
--
Christof Schmitt
-
To uns
available for
all SCSI devices? My first approach would be to add them to the sg
devices. Any comments?
If there are now objections, i will try to implement the ioctls for sg
devices, to see if this actually works.
--
Christof Schmitt
-
To unsubscribe from this list: send the line "unsubs
On Mon, May 21, 2007 at 11:45:13AM -0400, James Smart wrote:
> True - so this means that who-ever is setting the subchannel device
> permanent_port_name value needs to take into account this conversation,
> when T11.3 actually makes a choice on what it should be.
I will keep this in mind. Probabl
On Mon, May 14, 2007 at 11:56:38AM -0400, James Smart wrote:
> All true. But, there is the notion that there is a driver that thinks
> it's controlling the adapter, but it's actually talking to a virtual
> thing, that traps the driver's FLOGI's and turns it into FDISCs...
>
> >With zfcp, the har
James,
i try to understand what the introduction of the vports means for zfcp, since
this driver also supports NPIV. The documentation for the fc transport class
describes a driver that would fully control the adapter and the creation of
virtual address. Since you mentioned Xen, i assume that this
et. If every adapter would support
NPIV, zfcp could rely on the scan by the FC transport class, unfortunately,
this is not the case.
Christof Schmitt
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Tue, May 08, 2007 at 01:56:07AM +1000, Julian Calaby wrote:
> >From: Christof Schmitt <[EMAIL PROTECTED]>
> [snip]
> >- ZFCP_LOG_NORMAL("bug: unexpected inbound "
> >-
From: Christof Schmitt <[EMAIL PROTECTED]>
Correctly initialize the timer for FSF requests with jiffies + timeout.
Cc: Swen Schillig <[EMAIL PROTECTED]>
Acked-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Christof Schmitt <[EMAIL PROTECTED]>
---
Please consid
33 matches
Mail list logo
