Re: Fix up qla2xxx configuration bogosity
Linus, In looking through your latest git-pull and update of the Kconfig quirks in qla2xxx: Fix up qla2xxx configuration bogosity http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=e0aa8afd97536a9d94f82a07b4c4b3f05aef6f82;hp=e4ff4d7f9d85a2bc714307eb9113617182e62845 Would you also apply the attached patch which adds the appropriate FW_LOADER pre-requisite and a separate entry for ISP24xx support. Thanks to Adrian Bunk and Jesper Juhl for their efforts in fixing this quirk. Regards, Andrew Vasquez --- diff --git a/drivers/scsi/qla2xxx/Kconfig b/drivers/scsi/qla2xxx/Kconfig --- a/drivers/scsi/qla2xxx/Kconfig +++ b/drivers/scsi/qla2xxx/Kconfig @@ -7,6 +7,7 @@ config SCSI_QLA21XX tristate "QLogic ISP2100 host adapter family support" depends on SCSI_QLA2XXX select SCSI_FC_ATTRS + select FW_LOADER ---help--- This driver supports the QLogic 21xx (ISP2100) host adapter family. @@ -14,6 +15,7 @@ config SCSI_QLA22XX tristate "QLogic ISP2200 host adapter family support" depends on SCSI_QLA2XXX select SCSI_FC_ATTRS + select FW_LOADER ---help--- This driver supports the QLogic 22xx (ISP2200) host adapter family. @@ -21,6 +23,7 @@ config SCSI_QLA2300 tristate "QLogic ISP2300 host adapter family support" depends on SCSI_QLA2XXX select SCSI_FC_ATTRS + select FW_LOADER ---help--- This driver supports the QLogic 2300 (ISP2300 and ISP2312) host adapter family. @@ -29,6 +32,7 @@ config SCSI_QLA2322 tristate "QLogic ISP2322 host adapter family support" depends on SCSI_QLA2XXX select SCSI_FC_ATTRS + select FW_LOADER ---help--- This driver supports the QLogic 2322 (ISP2322) host adapter family. @@ -36,6 +40,16 @@ config SCSI_QLA6312 tristate "QLogic ISP63xx host adapter family support" depends on SCSI_QLA2XXX select SCSI_FC_ATTRS + select FW_LOADER ---help--- This driver supports the QLogic 63xx (ISP6312 and ISP6322) host adapter family. + +config SCSI_QLA24XX + tristate "QLogic ISP24xx host adapter family support" + depends on SCSI_QLA2XXX + select SCSI_FC_ATTRS + select FW_LOADER + ---help--- + This driver supports the QLogic 24xx (ISP2422 and ISP2432) host + adapter family. diff --git a/drivers/scsi/qla2xxx/Makefile b/drivers/scsi/qla2xxx/Makefile --- a/drivers/scsi/qla2xxx/Makefile +++ b/drivers/scsi/qla2xxx/Makefile @@ -1,5 +1,4 @@ EXTRA_CFLAGS += -DUNIQUE_FW_NAME -EXTRA_CFLAGS += -DCONFIG_SCSI_QLA24XX -DCONFIG_SCSI_QLA24XX_MODULE qla2xxx-y := qla_os.o qla_init.o qla_mbx.o qla_iocb.o qla_isr.o qla_gs.o \ qla_dbg.o qla_sup.o qla_rscn.o qla_attr.o - 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
Re: Incorrect driver getting loaded for Qlogic FC-HBA
On Wed, 27 Jul 2005, Rajat Jain wrote: > On 7/27/05, Andrew Vasquez <[EMAIL PROTECTED]> wrote: > > > > A similar problem was noted with RHEL4, it seems the modules.pcimap > > and pci.ids file were correct, but the pcitable file contained entries > > for all ql[ae]23xx based HBAs to load qla2300.ko. > > > > It's my understanding that this was fixed for RHEL4 U1. Which distro > > are you using? If you are using RHEL, and are still having problems, > > I'd suggest you file a report with Redhat. > > > > Regards, > > Andrew Vasquez > > > > BINGO! I AM using RHEL 4. So does that mean I can rectify the problem > by making appropriate changes to "pcitable" file? I'm trying to get a firm answer from the folks who originally discvoered the problem some time back, it seems you have two options: - during installation of RHEL4 (and not RHEL4U1), load with the 'noprobe' option: linux noprobe and manually select the appropriate drivers to load. - (post installation) modify the /etc/modprobe.conf to and rename the qla2300 entry to qla2322 (i.e.): alias scsi_hostadapter1 qla2322 modify the modules.pcimap table to load qla2322 for the 2322 device-id: qla2300 0x1077 0x2322 ... to: qla2322 0x1077 0x2322 ... Beyond that, I'd suggest you log a report with Redhat, as that's the extent of the workaround knowledge without going to RHEL4U1. Hope this helps, Andrew Vasquez - 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
Re: [PATCH] Revert accidental Makefile change
On Wed, 27 Jul 2005, Pavel Roskin wrote: > In the current git kernel, the qla2xxx.ko module is build and installed, > although I have never requested it and I don't have any modules enabled. > > I found the corresponding entry in the git log (commit > fca297037127e524e8f61b3fc1c7a1886e5d757b), and it looks like that > the change in drivers/scsi/qla2xxx/Makefile was committed accidentally. > The comment doesn't refer to Makefile. > > Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]> > > diff --git a/drivers/scsi/qla2xxx/Makefile b/drivers/scsi/qla2xxx/Makefile > --- a/drivers/scsi/qla2xxx/Makefile > +++ b/drivers/scsi/qla2xxx/Makefile > @@ -1,6 +1,4 @@ > EXTRA_CFLAGS += -DUNIQUE_FW_NAME > -CONFIG_SCSI_QLA24XX=m > -EXTRA_CFLAGS += -DCONFIG_SCSI_QLA24XX -DCONFIG_SCSI_QLA24XX_MODULE > > qla2xxx-y := qla_os.o qla_init.o qla_mbx.o qla_iocb.o qla_isr.o qla_gs.o \ > qla_dbg.o qla_sup.o qla_rscn.o qla_attr.o > @@ -16,4 +14,3 @@ obj-$(CONFIG_SCSI_QLA22XX) += qla2xxx.o > obj-$(CONFIG_SCSI_QLA2300) += qla2xxx.o qla2300.o > obj-$(CONFIG_SCSI_QLA2322) += qla2xxx.o qla2322.o > obj-$(CONFIG_SCSI_QLA6312) += qla2xxx.o qla6312.o > -obj-$(CONFIG_SCSI_QLA24XX) += qla2xxx.o I had already submitted a patch which took care of this: http://marc.theaimsgroup.com/?l=linux-scsi&m=112143863232467&w=2 There also appears to be some other (separate) Kbuild issues which I'm hashing through... Regards, Andrew Vasquez - 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
[PATCH] Revert accidental Makefile change
Hello! In the current git kernel, the qla2xxx.ko module is build and installed, although I have never requested it and I don't have any modules enabled. I found the corresponding entry in the git log (commit fca297037127e524e8f61b3fc1c7a1886e5d757b), and it looks like that the change in drivers/scsi/qla2xxx/Makefile was committed accidentally. The comment doesn't refer to Makefile. Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]> diff --git a/drivers/scsi/qla2xxx/Makefile b/drivers/scsi/qla2xxx/Makefile --- a/drivers/scsi/qla2xxx/Makefile +++ b/drivers/scsi/qla2xxx/Makefile @@ -1,6 +1,4 @@ EXTRA_CFLAGS += -DUNIQUE_FW_NAME -CONFIG_SCSI_QLA24XX=m -EXTRA_CFLAGS += -DCONFIG_SCSI_QLA24XX -DCONFIG_SCSI_QLA24XX_MODULE qla2xxx-y := qla_os.o qla_init.o qla_mbx.o qla_iocb.o qla_isr.o qla_gs.o \ qla_dbg.o qla_sup.o qla_rscn.o qla_attr.o @@ -16,4 +14,3 @@ obj-$(CONFIG_SCSI_QLA22XX) += qla2xxx.o obj-$(CONFIG_SCSI_QLA2300) += qla2xxx.o qla2300.o obj-$(CONFIG_SCSI_QLA2322) += qla2xxx.o qla2322.o obj-$(CONFIG_SCSI_QLA6312) += qla2xxx.o qla6312.o -obj-$(CONFIG_SCSI_QLA24XX) += qla2xxx.o -- Regards, Pavel Roskin - 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
Request to add EMC Invista to the v2.4.x SCSI Blacklist...
Hi, I'd like to request that the enclosed patch to scsi_scan.c be considered for inclusion in the v2.4.x kernel. This would add support for sparse LUNs and large LUNs for the EMC Invista product. Thanks for your consideration. Heather <> scsi_scan_invista.patch Description: Binary data
Request to add EMC Invista to the v2.6.x SCSI Blacklist...
Hi, I'd like to request that the enclosed patch to scsi_devinfo.c be considered for inclusion in the v2.6.x kernel. This would add support for sparse LUNs and large LUNs for the EMC Invista product. Thanks for your consideration. Heather <> scsi_devinfo_invista.patch Description: Binary data
Re: lpfc: System freezing if fiber is broken
Mike Anderson wrote:
Bodo Stroesser [EMAIL PROTECTED] wrote:
Hi James,
disrupting a working FC connection makes my i386 SMP server
(2.6.12.2) freeze just one or two seconds after this.
I'm normally using lpfc_nodev_tmo = 1. When I change this to the
default value of 35, the system stalls about 36 seconds after
disruption. So I guess, the problem is caused by nodev_tmo
expiring.
I activated the nmi_watchdog, but no output.
What can I do to analyze this problem?
Does changing the timeout for a scsi device also alter the problem. In the
past people have seen issues of the nodev_tmo expiring near the scsi
timeout. This past cases lead to devices being offlined, but may this
could be causing a different symptom on your system.
The amount of time between cutting the connection and the system freezing
is nearly the same as lpfc_nodev_tmo. Using the default nodev_tmo of 35 seconds
results in about 36 seconds, while setting nodev_tmo to 1 results in
2 seconds. As the devices on the Fibre Channel are tapedrives scsi timeout is
900 seconds.
There are 8 tests running that write 8 tape-LUNs at the same SCSI target.
If the connection is broken, some of the tests immediately receive a bad
result for write(), some keep waiting for a result.
Meanwhile I also did some tests with timeout set to 5 and nodev_tmo to 35
(The test I'm running doesn't fail with that small timeout). Those tests, that
do not receive a bad result, stay waiting for result even after 5 second timeout
is expired. In most cases, the system doesn't freeze after nodev_tmo with this
test.
But about 5 seconds after plugging FC cable again, it freezes.
You can change the timeout for the device by echoing a higher value into
/sys/bus/scsi/devices/${nexus}/timeout.
Is this a full system freeze or only the controlling console?
Full freeze, no more replies via console or network.
-andmike
--
Michael Anderson
[EMAIL PROTECTED]
-
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
Re: Updated Patch for ServeRAID V7.12.02
Randy,
1.) Install Thunderbird extension "Edit Config Files 1.3".
2.) Add these two lines in user.js :
pref("mailnews.send_plaintext_flowed", false);// RFC 2646
pref("mailnews.display.disable_format_flowed_support", true);
3.) Set "Wrap plain text messages at 0 characters" under "Options / Composition"
Thanks to Luben Tuikov, who guided me through all this. If you have any
further questions, he is probably the guy to ask ...
Jack
On 7/26/2005 11:11 PM, randy_dunlap wrote:
> On Tue, 26 Jul 2005 10:20:33 -0400 Jack Hammer wrote:
>
>
>>I switched to Thunderbird email, so the line wrapping caused by Outlook
>>should be resolved here.
>
>
> for the rest of us, how do you put a patch inline (not as an
> attachment) with thunderbird? have they added that capability
> recently? It would certainly go a long way to making thunderbird
> usable for kernel patches...
>
> Maybe it helps not to use tabs in the source files very much?
>
> Thanks,
> ---
> ~Randy
>
-
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
exporting TCQ functionality to the kernel in SYMBIOS/NCR 53C8XX driver
Hi Matthew,
Does this patch makes sense to you ?
Could you consider this for inclusion into mainline ?
best regards,
Philipp
--
: Dipl-Ing Philipp Reisner Tel +43-1-8178292-50 :
: LINBIT Information Technologies GmbH Fax +43-1-8178292-82 :
: Schönbrunnerstr 244, 1120 Vienna, Austriahttp://www.linbit.com :
diff -ur linux-2.6.12+kdb/drivers/scsi/sym53c8xx_2/sym_glue.c linux-2.6.12+kdb+sym-patch/drivers/scsi/sym53c8xx_2/sym_glue.c
--- linux-2.6.12+kdb/drivers/scsi/sym53c8xx_2/sym_glue.c 2005-07-27 10:54:47.0 +0200
+++ linux-2.6.12+kdb+sym-patch/drivers/scsi/sym53c8xx_2/sym_glue.c 2005-07-27 11:07:47.0 +0200
@@ -494,7 +494,14 @@
* Select tagged/untagged.
*/
lp = sym_lp(tp, sdev->lun);
- order = (lp && lp->s.reqtags) ? M_SIMPLE_TAG : 0;
+if (lp && lp->s.reqtags) {
+ if (cmd->request->flags & REQ_HARDBARRIER)
+ order = M_ORDERED_TAG;
+ else
+ order = M_SIMPLE_TAG;
+ } else {
+ order = 0 ;
+ }
/*
* Queue the SCSI IO.
@@ -1926,6 +1933,7 @@
.proc_info = sym53c8xx_proc_info,
.proc_name = NAME53C8XX,
#endif
+ .ordered_tag= 1,
};
static int attach_count;
Re: [PATCH] drivers/scsi/st.c: add command and sense history
The following comments are based on looking at the patch, not testing it.
The tape devices do not provide much information about problems via the normal
API: mostly it just tells that something went wrong. The driver prints the
sense data to the kernel log but this information may not be accessible and/or
it is difficult to connect it to the specific problem at hand. Exporting the
sense data in some form is a better (although not perfect) method to give more
information in case of problems.
On Fri, 22 Jul 2005, Andy Stevens wrote:
> Hello SCSI tapers,
>
> Attached is a patch to add some functionality the st driver so that you can
> monitor the most recent SCSI command and sense buffer. This info is made
> available via sysfs attributes. I want to add these attributes in order to do
> better error processing in some custom tape software which I am writing. This
> patch has been tested on Linux kernel 2.6.12.
>
> The new functionality is as follows:
>
> 1) the most recent "relevant" SCSI command and sense are stored in hex format
> in:
>
> /sys/class/scsi_tape/stN/last_cmnd
> /sys/class/scsi_tape/stN/last_sense
>
Using two files is problematic: the user can't be sure that last_sense is
really related to last_cmnd. If they are in the same file, a single read could
enforce this. (The implementation does not contain the necessary locking. I
don't think it is necessary at this phase but the single file approach would
make atomicity possible if desired.)
> When I say "relevant" SCSI command, I mean: occasionally the most recent SCSI
> command is not the one of interest, e.g. when encountering an ILI, the driver
> will automatically backspace to the beginning of the block. However, the
> last_cmnd and last_sense will show the results of the read error, not the
> backspace.
>
This is the reason why this should be in the ULD. If only the most recent
data would be exported, it could be done at midlevel to benefit all SCSI
devices.
> 2) The raw sense data is also decoded into English language for primary sense
> key, extended sense, and ILI/FM/EOM flags in these sysfs files:
>
> /sys/class/scsi_tape/stN/primary_sense
> /sys/class/scsi_tape/stN/extended_sense
> /sys/class/scsi_tape/stN/sense_flags
>
I don't think these are necessary. Anyway, the sysfs data should be either
single values or an array of values. The contents of the files must be
explained elsewhere (linux/Documentation/scsi/st.txt).
However, I would like to discuss exporting selected fields of the sense data
instead
of the raw data as an alternative. This would make interpretation of the data
easier when devices supporting the descriptor based sense data start
appearing. The values exported could be: sense key, ASC, ASCQ, flags (FM, EOM,
ILI), information field. What do the users really need?
> Details of implementation:
>
> 1) added data fields "last_cmnd" and "last_sense" to struct st_cmdstatus for
> storage of most recent command and sense data. Removed unused "last_cmnd" and
> "last_sense" fields from struct scsi_tape.
>
> 2) added routine st_record_last_command() to save command and sense data
>
> 3) added calls to st_record_last_command() in appropriate locations in the
> code.
>
> 4) added arg to st_int_ioctl() to indicate whether or not to record the SCSI
> command (necessary so that we can record the "relevant" command)
>
> 5) added routines for sysfs attribute files
>
> This is my first time submitting a patch to the list, please go easy on me!!
>
Could you in future make patches from the linux source tree root using
'diff -up' (i.e., the path to st.c would be linux/drivers/scsi/st.c; the file
linux/Documentation/SubmittingPatches contains a lot of useful
information). Appending the diff instead of putting it into an attachment
would make commenting easier for some of us.
> --- st.c.orig 2005-06-17 15:48:29.0 -0400
> +++ st.c 2005-07-22 15:20:06.0 -0400
> @@ -17,7 +17,7 @@
> Last modified: 18-JAN-1998 Richard Gooch <[EMAIL PROTECTED]> Devfs support
> */
>
> -static char *verstr = "20050312";
> +static char *verstr = "20050706";
>
> #include
>
> @@ -215,7 +215,7 @@
> static int find_partition(struct scsi_tape *);
> static int switch_partition(struct scsi_tape *);
>
> -static int st_int_ioctl(struct scsi_tape *, unsigned int, unsigned long);
> +static int st_int_ioctl(struct scsi_tape *, unsigned int, unsigned long,
> int);
>
>
> #include "osst_detect.h"
> @@ -264,6 +264,29 @@
> return tape->disk->disk_name;
> }
>
> +static void st_clear_last_command(struct scsi_tape *STp)
> +{
> + /* clear last command and last sense */
> + memset(STp->buffer->cmdstat.last_cmnd,0,MAX_COMMAND_SIZE);
> + memset(STp->buffer->cmdstat.last_sense,0,SCSI_SENSE_BUFFERSIZE);
> +}
> +
> +static void st_record_last_command(struct scsi_tape *STp, struct
> scsi_request *SRpnt)
> +{
> + int i;
> +
> + st_clear_last_command(STp);
> +
Not necessary.
> + /* make
