headers
Patrick Mansfield | 1 Oct 2003 02:21
Picon
Favicon

[PATCH] consolidate and log scsi command on send and completion

Hi -

Patch against 2.6.0-test6.

Consolidate and nicely log the scsi_device and scsi command before sending
and after completing a command to an adapter driver.

diff -uprN -X /home/patman/dontdiff bl-25/drivers/scsi/scsi.c bl-25-scmd-log/drivers/scsi/scsi.c
--- bl-25/drivers/scsi/scsi.c	Mon Sep 29 12:21:09 2003
+++ bl-25-scmd-log/drivers/scsi/scsi.c	Tue Sep 30 14:24:17 2003
 <at>  <at>  -351,6 +351,124  <at>  <at>  void scsi_destroy_command_freelist(struc
 	up(&host_cmd_pool_mutex);
 }

+#ifdef CONFIG_SCSI_LOGGING
+void scsi_log_send(struct scsi_cmnd *cmd)
+{
+	unsigned int level;
+	struct scsi_device *sdev;
+
+	/*
+	 * If ML QUEUE log level is greater than or equal to:
+	 *
+	 * 1: nothing (match completion)
+	 *
+	 * 2: log opcode + command of all commands
+	 *
+	 * 3: same as 2 plus dump cmd address
+	 *
+	 * 4: same as 3 plus dump extra junk
(Continue reading)

Permalink | Reply | 2 comments |
headers
Patrick Mansfield | 1 Oct 2003 02:23
Picon
Favicon

Re: [PATCH] consolidate and log scsi command on send and completion

Some sample output showing the command logging (with CONFIG_SCSI_CONSTANTS
enabled).

Of course after shutting off syslogd :-(

And with scsi logging for ml queue of 2 and ml complete of 2 via:

	sysctl -w dev.scsi.logging_level=0x2400

FYI, if you want both ml queue and ml complete both set:

	to 	use scsi_logging_level
	1		0x1200
	2		0x2400
	3		0x3600
	4		0x4800

Output for scanning host3 id 0, a0 is REPORT LUNS, interspersed with writes 
to the root disk <0:0:0:0>, and partition information:

scsi <3:0:0:0> send                  UNKNOWN(0xa0) 00 00 00 00 00 00 00 04 08 00 00 
scsi <3:0:0:0> done SUCCESS        0 UNKNOWN(0xa0) 00 00 00 00 00 00 00 04 08 00 00 
scsi <3:0:0:1> send                  Inquiry 00 00 00 24 00 
scsi <3:0:0:1> done SUCCESS        0 Inquiry 00 00 00 24 00 
  Vendor: IBM       Model: 3542              Rev: 0520
  Type:   Direct-Access                      ANSI SCSI revision: 03
scsi(3:0:0:1): Enabled tagged queuing, queue depth 64.
scsi <3:0:0:1> send                  Test Unit Ready 00 00 00 00 00 
scsi <3:0:0:1> done SUCCESS        0 Test Unit Ready 00 00 00 00 00 
scsi <3:0:0:1> send                  Read Capacity 00 00 00 00 00 00 00 00 00
(Continue reading)

Permalink | Reply | 1 comment |
headers
Douglas Gilbert | 1 Oct 2003 03:22

[PATCH] constants.c [was: consolidate and log scsi command on send and completion]

Patrick Mansfield wrote:
> Some sample output showing the command logging (with CONFIG_SCSI_CONSTANTS
> enabled).
> 
> Of course after shutting off syslogd :-(
> 
> And with scsi logging for ml queue of 2 and ml complete of 2 via:
> 
> 	sysctl -w dev.scsi.logging_level=0x2400
> 
> FYI, if you want both ml queue and ml complete both set:
> 
> 	to 	use scsi_logging_level
> 	1		0x1200
> 	2		0x2400
> 	3		0x3600
> 	4		0x4800
> 
> Output for scanning host3 id 0, a0 is REPORT LUNS, interspersed with writes 
> to the root disk <0:0:0:0>, and partition information:
> 
> scsi <3:0:0:0> send                  UNKNOWN(0xa0) 00 00 00 00 00 00 00 04 08 00 00 
> scsi <3:0:0:0> done SUCCESS        0 UNKNOWN(0xa0) 00 00 00 00 00 00 00 04 08 00 00 

looks good ....

However, drivers/scsi/constants.c does know about Report Luns??
Looks like a merging problem by Andries and me sometime back.
See attachment.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stepan Novotill | 1 Oct 2003 06:50
Picon
Favicon

urgent SCSI help please

What does this mean in /var/log/messages when I read data from DTF2 tapes?

kernel: sym53c875-1-≤5,*>: FAST-20 WIDE SCSI 40.0 MB/s (50.0 ns, offset 8)
last message repeated 11706 times
last message repeated 9539 times

Ive swapped out everything including all SCSI components, kernel versions, 
drivers, everything.

Funny the symbios driver (doesn't matter which flavor) won't load in 
/etc/modules.conf but will from rc.local on this PE2600 smp machine. There 
are two of these (HVD) Symbios-8751D cards installed.

Thanks from Stepan

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*  
http://join.msn.com/?page=features/virus

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Doug Ledford | 1 Oct 2003 07:38
Picon
Favicon

Re: urgent SCSI help please

On Wed, 2003-10-01 at 00:50, Stepan Novotill wrote:
> What does this mean in /var/log/messages when I read data from DTF2 tapes?
> 
> kernel: sym53c875-1-≤5,*>: FAST-20 WIDE SCSI 40.0 MB/s (50.0 ns, offset 8)
> last message repeated 11706 times
> last message repeated 9539 times
> 
> Ive swapped out everything including all SCSI components, kernel versions, 
> drivers, everything.

It means that your driver and the tape drive are constantly performing
speed negotiations.  Some drivers don't like it when the device
initiates speed negotiations (I'm not claiming that the sym drivers is
one of those, just that some don't).  However, I wouldn't be suprised if
the driver is accepting incoming negotiations, but then also initiating
a new negotiation cycle itself (I don't know this to be the case, but it
wouldn't suprise me too much).  Maybe that would cause your tape drive
to reissue it's negotiation.  Which would cause the driver to reissue
its negotiation.  Anyway, one thing to check is try making sure that the
tape drive isn't initiating speed negotiations.  It usually doesn't help
at all, and in some cases causes problems for drivers, so best to just
leave it off.  A lot of devices have a jumper or dip switch somewhere
that allows you to disable this.  The manuals usually call it Target
Initiated SDTR or Target Ininitiated Negotiation or something similar to
that.

HTH.

--

-- 
  Doug Ledford <dledford <at> redhat.com>     919-754-3700 x44233
(Continue reading)

Permalink | Reply | 0 comments |
headers
jd | 1 Oct 2003 21:19
Picon
Favicon

Re: 1st REVIEW : UNH iSCSI for 2.6-test5 - Questions


See below ...
--- Christoph Hellwig <hch <at> infradead.org> wrote:
> More comments:
> 
>  - unh_iscsi/security should really go away.  We have a nice crypto
> API
>    in 2.6 and late 2.4, but authentification really shouldn't be done
>    in kernelspace anyway.

    We're in the process of reviewing that API.

>  - kill iscsi_device.c.  A scsi LLDD has no business messing with
> device
>    nodes..
  DONE .. We never used it anyway .
>  - you're comment style is strange.  In kernel code we tend to use
> 
> /*
>  * Foo, blah
>  * baz..
>  */
> 
> not
> 
> /*
> 
> */
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
jd | 1 Oct 2003 21:34
Picon
Favicon

Re: 1st REVIEW : UNH iSCSI for 2.6-test5

Comments /questions below.
--- Jeff Garzik <jgarzik <at> pobox.com> wrote:
> jd wrote:
> > Hi,
> > 
> > Available for first Review & Comments.
> > 
> > The UNH iSCSI Project, a collaborative effort between the
> > UNH IOL and Hewlett Packard Company in Austin, Texas,
> > ( hosted at http://sourceforge.net/projects/unh-iscsi )
> > to produce a full feature, generic iSCSI implementation ,
> > has ported the 2.4.18/20 version of the iSCSI initiator to
> > Linux 2.6.test5 Kernel for consideration of inclusion for
> > future distribution.
> > 
> > A patch file is available for review at:
> > 
> > http://www.parisc-linux.org/~jpd/
> > 
> > Files included in the patch :
> > 
> >  drivers/scsi/Makefile
> >  drivers/scsi/Kconfig
> >  drivers/scsi/unh_iscsi
> >  drivers/scsi/unh_iscsi/initiator     # HBA & Data mover
> >  drivers/scsi/unh_iscsi/common        # Login and shared files
> >  drivers/scsi/unh_iscsi/security       $ SRP and CHAP login
> > 
> > Please submit comments to :
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Randy.Dunlap | 1 Oct 2003 21:23
X-Face

[PATCH] BusLogic: add error handling, fix queuecommand, docs.

Hi,

Bugzilla Bug 1086: BusLogic SCSI Driver Lacks Error Handling
  <URL:http://bugme.osdl.org/show_bug.cgi?id=1086>

Here's a patch to add error handling to BusLogic, as well as
fix its queuecommand to return 0/1 as required, and remove
some duplicate documentation.

I didn't address the use of 'check_region' (deprecated).

Comments?

Thanks.
--
~Randy

patch_name:	buslogic_ehupdate_t6.patch
patch_version:	2003-10-01.12:24:50
author:		Randy.Dunlap <rddunlap <at> osdl.org>
description:	update BusLogic driver to use current SCSI
		  error handling model;
		modify queuecommand to return 0 or 1 depending for
		  success or failure respectively;
		remove duplicate doc comments -- use
		  Documentation/scsi/BusLogic.txt only;
product:	Linux
product_versions: 2.6.0-test6
diffstat:	=
 Documentation/scsi/BusLogic.txt |    2
(Continue reading)

Permalink | Reply | 9 comments |
headers
Mike Anderson | 1 Oct 2003 23:48
Picon
Favicon

Re: [PATCH] BusLogic: add error handling, fix queuecommand, docs.

Randy.Dunlap [rddunlap <at> osdl.org] wrote:
> +/* Error Handling (EH) support */
> +
> +static int BusLogic_abort(Scsi_Cmnd *SCpnt)
> +{
> +	return FAILED;
> +}
> +
> +static int BusLogic_bus_reset(Scsi_Cmnd *SCpnt)
> +{
> +	return FAILED;
> +}
> +
> +static int BusLogic_device_reset(Scsi_Cmnd *SCpnt)
> +{
> +	return FAILED;
> +}
> +

If the functions are just going to return FAILED you may want to
consider leaving them out. Having these functions return fail will cause
the output to be noisy. Either with this noisy output or not the
recovery will end up at BusLogic_host_reset.

-andmike
--
Michael Anderson
andmike <at> us.ibm.com

-
(Continue reading)

Permalink | Reply | 8 comments |
headers
Randy.Dunlap | 1 Oct 2003 23:43
X-Face

Re: [PATCH] BusLogic: add error handling, fix queuecommand, docs.

On Wed, 1 Oct 2003 14:48:18 -0700 Mike Anderson <andmike <at> us.ibm.com> wrote:

| Randy.Dunlap [rddunlap <at> osdl.org] wrote:
| > +/* Error Handling (EH) support */
| > +
| > +static int BusLogic_abort(Scsi_Cmnd *SCpnt)
| > +{
| > +	return FAILED;
| > +}
| > +
| > +static int BusLogic_bus_reset(Scsi_Cmnd *SCpnt)
| > +{
| > +	return FAILED;
| > +}
| > +
| > +static int BusLogic_device_reset(Scsi_Cmnd *SCpnt)
| > +{
| > +	return FAILED;
| > +}
| > +
| 
| If the functions are just going to return FAILED you may want to
| consider leaving them out. Having these functions return fail will cause
| the output to be noisy. Either with this noisy output or not the
| recovery will end up at BusLogic_host_reset.

Yes, I noticed that (later).  I'll be glad to remove them.

This was the result of cut-and-paste from another driver.
(Continue reading)

Permalink | Reply | 7 comments |

Gmane