headers
kallol | 1 May 2005 03:02

LSI Logic's Ultra320 320-4X RAID adapter


Hello,
      We have been evaluting different IO adapters for a storage system vendor.

LSI logic's 320-4X RAID controller seems to be a good choice.

There is an issue with the system on which we are measuring performance.
The memory space PCI register access can not be used.

Question #1: Does 320-4X support IO Space device register access?
Question #2: Do we have a linux driver for it that supports IO ports also?

The megaraid linux driver seems to check the BAR0, if it is memory bar then mem
space is used otherwise IO space.

May be the adapter supporting memory space also support IO space access.

Thanks,
Kallol
Permalink | Reply | 0 comments |
headers
Jeremy Higdon | 1 May 2005 07:18
Picon
Favicon

[PATCH 2.6.12-rc3] qla1280.c - fix result for device Busy and Queue Full

I discovered that the qla1280 driver does not send the correct status
to the midlayer when it gets Queue Full or Busy from a device.

Signed-off-by: Jeremy Higdon <jeremy <at> sgi.com>

--- drivers/scsi/qla1280.c.orig	2005-04-30 02:21:08.000000000 -0700
+++ drivers/scsi/qla1280.c	2005-04-30 21:57:21.000000000 -0700
 <at>  <at>  -4038,11 +4038,10  <at>  <at> 
 			scsi_status, handle);
 	}

-	/* Target busy */
-	if (scsi_status & SS_BUSY_CONDITION &&
-	    scsi_status != SS_RESERVE_CONFLICT) {
-		CMD_RESULT(cmd) =
-			DID_BUS_BUSY << 16 | (scsi_status & 0xff);
+	/* Target busy or queue full */
+	if ((scsi_status & 0xFF) == SAM_STAT_TASK_SET_FULL ||
+	    (scsi_status & 0xFF) == SAM_STAT_BUSY) {
+		CMD_RESULT(cmd) = scsi_status & 0xff;
 	} else {

 		/* Save ISP completion status */
-
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 | 0 comments |
headers
Mogens Valentin | 1 May 2005 11:01
Picon

Re: [Question] Does the kernel ignore errors writng to disk?

Alan Cox wrote:
> The next question is what the I/O device does with the data. SCSI disks
> will cache but the scsi layer uses tags and if neccessary turns the
> cache off on the drive. In other words you should get that behaviour
> correctly on SCSI media.
> 
> The default IDE behaviour doesn't turn write cache off and the IDE
> device may re-order writes and ack them before they hit storage. IDE
> lacks tags, and tends to have poor performance on cache flush commands.
> With the barrier support on the right thing should occur, or with hdparm
> used to turn the write cache off.

Is this IDE behaviour confined to IDE drives only?
SATA, when using libata, will solemnly be part of the SCSI chain, and 
hense not subject to your mentioned write cache problem, right?

--

-- 
Kind regards,
Mogens Valentin

-
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 | 0 comments |
headers
shogunx | 1 May 2005 17:31

RE: Emulex fibre channel HBA support and SAN connection

On Sat, 30 Apr 2005 James.Smart <at> Emulex.Com wrote:

> IP over FC was removed from our 8.x series driver as we pushed for
> upstream acceptance. So, you must be running a older driver. Please
> go through the proper support channels for that
 driver rev.

This was the 2.01g source tree.  I have a mix of LP7000E's and 6000's
from an IBM ESS 2105 Shark, of which I am trying to do IP over
FC with the 7000's.  The Sharks were decommissioned and I acquired them at
a military surplus auction.  I have yanked the HBA's from the series of
pci bridges that IBM had them encased in, so now they rest on the main
pci bus.  So I'm not sure what the normal support
channels would be, as I got all of the kit used and IBM won't support my
port for some reason.  I decided that linux
would be better on the shark than AIX, so now I'm to the point of trying
to get the IP over FC working.  I get a device not found error on the lpfn
with Suse's 2.6 for ppc64... the config file is identical to the x86
implementation below.  I couldn't get them to compile with 2.6.8.

I've tried this on x86 also, and though your code compiles cleanly against
my openmosix and hostap patched 2.4.20, when the lpfn modules loads, the
ksoftirqd_CPU0 taxes the processor to 100%.  Rmmod the IP over FC, and bye
bye load.  This is with no actual fiber connected to the hba.

I've got the SerialRAID cards from the shark sitting loose here if any
other LKMLers would like to take a crack at them.  IBM told me "No Code.
No Binary.  Run AIX or nothing."

Thanks,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kai Makisara | 1 May 2005 19:56
Picon
Picon

Re: [PATCH 2.6.11.8] SCSI tape security: require CAP_SYS_RAWIO for SG_IO etc.

On Sat, 30 Apr 2005, Kai Makisara wrote:

> The patch at the end is against 2.6.11.8.
> 
> The kernel currently allows any user permitted to access the tape device file
> to send the tape drive commands that may either make the tape drivers internal
...
> filtering. This patch solves the problem for tapes and no more elaborate
> patches are needed. If those are merged to the kernel, this patch can be reversed.
> 
> Signed-off-by: Kai Makisara <kai.makisara <at> kolumbus.fi>
> 
> --- linux-2.6.11.8/drivers/scsi/st.c	2005-03-03 21:10:36.000000000 +0200
> +++ linux-2.6.11.8-k1/drivers/scsi/st.c	2005-04-30 09:57:21.000000000 +0300
>  <at>  <at>  -3414,7 +3414,10  <at>  <at>  static int st_ioctl(struct inode *inode,
>  		case SCSI_IOCTL_GET_BUS_NUMBER:
>  			break;
>  		default:
> -			i = scsi_cmd_ioctl(file, STp->disk, cmd_in, p);
> +			if (!capable(CAP_SYS_RAWIO))
> +				i = -EPERM;
> +			else
> +				i = scsi_cmd_ioctl(file, STp->disk, cmd_in, p);
>  			if (i != -ENOTTY)
>  				return i;
>  			break;

Please hold this patch. Testing the corresponding patch for 2.6.12-rc
showed that this is too restrictive. Best to wait until the next versions 
will be reviewed on the linux-scsi list and merged into -rc.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kai Makisara | 1 May 2005 20:11
Picon
Picon

[PATCH 2.6] SCSI tape: fix permissions for SG_IO, etc.

This patch is against 2.6.12-rc3 + linus-patch from April 30. The patch
contains the following fixes:

- CAP_SYS_RAWIO is used instead of CAP_SYS_ADMIN; fix from Alan Cox
- only direct sending of SCSI commands requires this permission
- the st status is modified is successful unload is performed using
  SCSI_IOCTL_STOP_UNIT

Signed-off-by: Kai Makisara <kai.makisara <at> kolumbus.fi>

--- linux-2.6.12-rc3-300405/drivers/scsi/st.c	2005-04-05 22:36:16.000000000 +0300
+++ linux-2.6.12-rc3-300405-k1/drivers/scsi/st.c	2005-05-01 20:45:27.000000000 +0300
 <at>  <at>  -17,7 +17,7  <at>  <at> 
    Last modified: 18-JAN-1998 Richard Gooch <rgooch <at> atnf.csiro.au> Devfs support
  */

-static char *verstr = "20050312";
+static char *verstr = "20050501";

 #include <linux/module.h>

 <at>  <at>  -29,6 +29,7  <at>  <at>  static char *verstr = "20050312";
 #include <linux/string.h>
 #include <linux/errno.h>
 #include <linux/mtio.h>
+#include <linux/cdrom.h>
 #include <linux/ioctl.h>
 #include <linux/fcntl.h>
 #include <linux/spinlock.h>
 <at>  <at>  -50,6 +51,7  <at>  <at>  static char *verstr = "20050312";
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Bottomley | 1 May 2005 22:29
Favicon

Re: 2.6.12-rc3 won't boot from aic7899

On Fri, 2005-04-29 at 05:54 -0500, K.R. Foley wrote:
> I tried the patch that you sent. It looks like its blowing up now in 
> ahc_send_async. At least now we have an oops to look at. I started 
> trying to trace through this, but ran out of time. I am sending it on to 
> you in hopes that you'll be able to figure this out much quicker than I can.

Well ... there's odd news from this.  I can simulate this pretty well
just by cutting the upper 8 bits from a wide cable (Which I got right on
the second attempt; silly me for assuming that the strands in a ribbon
cable would be numbered 1,2,3 etc. 1,35,2,36 is much more logical ...)

However, when I do this, I get:

  Vendor: HP 36.4G  Model: ST336607LW        Rev: HPC3
  Type:   Direct-Access                      ANSI SCSI revision: 03
scsi11:A:1:0: Tagged Queuing enabled.  Depth 32
 target11:0:1: Beginning Domain Validation
(scsi11:A:1): 6.600MB/s transfers (16bit)
(scsi11:A:1:0): parity error detected in Data-in phase. SEQADDR(0x84) SCSIRATE(0x80)
 target11:0:1: Wide Transfers Fail
(scsi11:A:1): 3.300MB/s transfers
(scsi11:A:1): 40.000MB/s transfers (40.000MHz, offset 63)
 target11:0:1: Ending Domain Validation

Which is what I expected, and also shows that it's not as simple as I
was thinking: the aic7xxx not propagating the errors and trying to fix
up on its own.

However, it could be the command is getting lost in error recovery.
Could you enable logging and boot with the parameter
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mogens Valentin | 2 May 2005 01:35
Picon

Re: 2.6.12-rc3 won't boot from aic7899

K.R. Foley wrote:

 > James Bottomley wrote:
 >
 >>
 >>> Apr 24 23:23:30 porky kernel: scsi1 : Adaptec AIC7XXX EISA/VLB/PCI 
SCSI HBA DRIVER, Rev 6.2.36
 >>> Apr 24 23:23:30 porky kernel:         <Adaptec aic7899 Ultra160 
SCSI adapter>
 >>> Apr 24 23:23:30 porky kernel:         aic7899: Ultra160 Wide 
Channel B, SCSI Id=7, 32/253 SCBs
 >>> Apr 24 23:23:30 porky kernel: Apr 24 23:23:30 porky kernel: 
(scsi1:A:0): 20.000MB/s transfers (20.000MHz, offset 15)
 >>> Apr 24 23:23:31 porky kernel:   Vendor: SEAGATE   Model: SX118273LC 
        Rev: 6679
 >>
 >>
 >> Yes, that's what I suspected.  Here the internal aic7xxx DV has silently
 >> configured the drive to be narrow.  Probably because of cable damage or
 >> something else.
 >>
 > Sorry I missed this before. The reason it is doing this is because 
this drive is connected using an adapter that converts an LC/LV (is this 
correct, off the top of my head) interface into a standard SCSI (narrow) 
interface. Could this be HELPING me here?

Probably the opposite, but thats what you meant anyway, right :-

I saw this on two Intel 440LX dual pIII 500/550 mobos, a bit different 
in age and scsi composition.
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Bottomley | 2 May 2005 01:58
Favicon

[PATCH] fix command retries in spi_transport class

This will likely fix the adaptec domain validation problem.  However,
it's not a true fix if the mid-layer is losing commands, it just makes
it far less likely to get into that situation.

The premise is that domain validation is likely to trigger errors which
it wants to know about, so the only time it should be retrying them is
when it gets a unit attention (likely as the result of a previous bus or
device reset).  Ironically, the previous coding retried three times in
all cases except those of unit attention.  The attached fixes this to do
the right thing.

James

--- k/drivers/scsi/scsi_transport_spi.c  (mode:100644)
+++ l/drivers/scsi/scsi_transport_spi.c  (mode:100644)
 <at>  <at>  -22,6 +22,7  <at>  <at> 
 #include <linux/init.h>
 #include <linux/module.h>
 #include <linux/workqueue.h>
+#include <linux/blkdev.h>
 #include <asm/semaphore.h>
 #include <scsi/scsi.h>
 #include "scsi_priv.h"
 <at>  <at>  -41,6 +42,11  <at>  <at> 

 #define SPI_MAX_ECHO_BUFFER_SIZE	4096

+#define DV_LOOPS	3
+#define DV_TIMEOUT	(10*HZ)
+#define DV_RETRIES	3	/* should only need at most
(Continue reading)

Permalink | Reply | 6 comments |
headers
Adrian Bunk | 2 May 2005 03:47
Picon

[2.6 patch] drivers/scsi/sym53c416.c: fix a wrong check

The Coverity checker found that this for loop was wrong.

This patch changes it to what seems to be intended.

Signed-off-by: Adrian Bunk <bunk <at> stusta.de>

---

This patch was already sent on:
- 10 Apr 2005

--- linux-2.6.12-rc2-mm2-full/drivers/scsi/sym53c416.c.old	2005-04-09 22:16:04.000000000 +0200
+++ linux-2.6.12-rc2-mm2-full/drivers/scsi/sym53c416.c	2005-04-09 22:16:28.000000000 +0200
 <at>  <at>  -803,19 +803,19  <at>  <at> 
 static int sym53c416_host_reset(Scsi_Cmnd *SCpnt)
 {
 	int base;
 	int scsi_id = -1;	
 	int i;

 	/* printk("sym53c416_reset\n"); */
 	base = SCpnt->device->host->io_port;
 	/* search scsi_id - fixme, we shouldnt need to iterate for this! */
-	for(i = 0; i < host_index && scsi_id != -1; i++)
+	for(i = 0; i < host_index && scsi_id == -1; i++)
 		if(hosts[i].base == base)
 			scsi_id = hosts[i].scsi_id;
 	outb(RESET_CHIP, base + COMMAND_REG);
 	outb(NOOP | PIO_MODE, base + COMMAND_REG);
 	outb(RESET_SCSI_BUS, base + COMMAND_REG);
(Continue reading)

Permalink | Reply | 0 comments |

Gmane