Hello,
does anybody of you have a recommendation for a SCSI HBA that supports
16 byte cdb's to go around the 2TB limit with external raid systems?
Thanks for any help
Carsten John
--
Max Planck Institut fuer marine Mikrobiologie
- Network Administration -
Celsiustr. 1
D-28359 Bremen
Tel.: +49
On Tue, Jan 30, 2007 at 04:42:28PM -0500, Salyzyn, Mark wrote:
One shortcoming of the driver relationship with the kernel is that there
is no standard means of having the insmod parameters associated with a
driver to also be parsed and set by the kernel parameter line.
Actually there is. In
On Tue, Jan 30, 2007 at 03:31:25PM -0800, Wu, Gilbert wrote:
Subject: [PATCH] scsi: Update Aic94xx SAS/SATA Linux open source device
driver for new sequence firmware.
Contribution:
Ed Chim [EMAIL PROTECTED]
Gilbert Wu [EMAIL PROTECTED]
Change Log:
1.Use dword
On Wed, 2007-01-31 at 09:56 +, Christoph Hellwig wrote:
On Tue, Jan 30, 2007 at 03:31:25PM -0800, Wu, Gilbert wrote:
Subject: [PATCH] scsi: Update Aic94xx SAS/SATA Linux open source device
driver for new sequence firmware.
Contribution:
Ed Chim [EMAIL PROTECTED]
On Mon, 2007-01-29 at 09:40 -0700, Eric Moore wrote:
export symbol to be used in 1st fusion patch
Signed-off-by: Eric Moore [EMAIL PROTECTED]
This is wrong. the int represents our internal coding of the 8 byte
extended LUN (currently it's a lossy transform that only allows up to
two level
I have implemented Christoph's suggestions and comments in his reply
to my RFC.
Due to a firmware mismatch between a host and target (names withheld to
protect the innocent?), the LLDD was returning DID_RESET for every
i/o
Move scsi_release_buffers() call so that buffers are retained until
after a determination is made about whether the command will be
requeued via scsi_queue_insert(). Doing so allows a command which
receives DID_RESET to be immediately queued to the driver using
the original scsi_cmnd, thus
Limit lifetime of scsi commands receiving DID_RESET status.
Signed-off-by: Michael Reed [EMAIL PROTECTED]
Limit lifetime of scsi commands receiving DID_RESET status.
Signed-off-by: Michael Reed [EMAIL PROTECTED]
--- rg61u/include/scsi/scsi.h 2006-10-31 21:08:47.0 -0600
+++
--- James Bottomley [EMAIL PROTECTED] wrote:
On Wed, 2007-01-31 at 09:56 +, Christoph Hellwig wrote:
On Tue, Jan 30, 2007 at 03:31:25PM -0800, Wu, Gilbert wrote:
Subject: [PATCH] scsi: Update Aic94xx SAS/SATA Linux open source device
driver for new sequence firmware.
On Wednesday, January 31, 2007 10:02 AM, James Bottomley wrote:
This is wrong. the int represents our internal coding of the 8 byte
extended LUN (currently it's a lossy transform that only allows up to
two level LUNs, so one day this will definitely change). No driver
should be using this
On Fri, 05 Jan 2007 07:10:09 -0800, Sumant Patro wrote:
This command clears the pending commands in the adapter
and re-initialize its internal RAID structure.
Without this change, megaraid driver either panics or fails to
initialize the adapter during kdump's
On Wed, 2007-01-31 at 12:44 -0700, Moore, Eric wrote:
On Wednesday, January 31, 2007 10:02 AM, James Bottomley wrote:
This is wrong. the int represents our internal coding of the 8 byte
extended LUN (currently it's a lossy transform that only allows up to
two level LUNs, so one day this
On Wednesday, January 31, 2007 1:49 PM, James Bottomley wrote:
Yes, I missed that. However, the mf (SCSIIORequest_t) comes back with
the 8 byte luns, couldn't you just run vdevice-lun through
int_to_scsilun and compare on that?
I'm really reluctant to export the lun to int lossy transform
Mark Lord wrote:
In an ideal world, we would use the existing ATA_12 opcode
to issue 12-byte ATA passthrough commands for libata ATAPI drives
from userspace.
But ATA_12 happens to have the same SCSI opcode value as the older
CD/RW BLANK command, widely used by cdrecord and friends.
So,
Tejun Heo wrote:
Mark Lord wrote:
..
So, to achieve ATA passthru capability for libata ATAPI,
we have to instead use the ATA_16 opcode: a 16-byte command.
SCSI normally disallows issuing 16-byte commands to 12-byte devices,
so special support has to be added for this.
I might have missed
Mark Lord wrote:
Tejun Heo wrote:
Mark Lord wrote:
..
So, to achieve ATA passthru capability for libata ATAPI,
we have to instead use the ATA_16 opcode: a 16-byte command.
SCSI normally disallows issuing 16-byte commands to 12-byte devices,
so special support has to be added for this.
I
James Bottomley wrote:
..
In SCSI, we're very careful only to use large commands where necessary,
so even for a 2TB array, you only see 16 byte commands for sectors
beyond 2TB. This essentially means that the capacity (and we do a
careful READ_CAPACITY(10) and only move on to READ_CAPACITY(16)
Tejun Heo wrote:
Anyways, this has never been guaranteed because
the limit is host wide.
But until very very recently, host wide meant just a single device
for libata. I was just assuming we did all of the fiddling to ensure
a minimal value there for some real reason.
But, yes, now we have
On Wed, 2007-01-31 at 15:54 -0700, Eric Moore wrote:
static int
+mptscsih_cmp_scsilun(struct scsi_lun * lun1, struct scsi_lun * lun2)
+{
+ int i;
+
+ for (i = 0; i 8 ; i++)
+ if (lun1-scsi_lun[i] != lun2-scsi_lun[i])
+ return 1;
+
+
The patch is specific to kdump scenario.
What I see in the log is cmd timeout(s) and is not related to the patch.
--Sumant
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matthias Urlichs
Sent: Wednesday, January 31, 2007 9:50 AM
To:
Mark Lord wrote:
Eric D. Mudama wrote:
Actually, it's possibly worse, since each failure in libata will
generate 3-4 retries. With existing ATA error recovery in the drives,
that's about 3 seconds per retry on average, or 12 seconds per
failure. Multiply that by the number of blocks past
Jeff Garzik wrote:
Mark Lord wrote:
Eric D. Mudama wrote:
Actually, it's possibly worse, since each failure in libata will
generate 3-4 retries. With existing ATA error recovery in the
drives, that's about 3 seconds per retry on average, or 12 seconds
per failure. Multiply that by the
Ric Wheeler wrote:
Mark Lord wrote:
Eric D. Mudama wrote:
Actually, it's possibly worse, since each failure in libata will
generate 3-4 retries.
(note: libata does *not* generate retries for medium errors;
the looping is driven by the SCSI mid-layer code).
It really beats the alternative
When libata reports a MEDIUM_ERROR to us, we *know* it's non-recoverable,
as the drive itself has already done internal retries (libata uses the
with retry ATA opcodes for this).
This depends on the firmware. Some of the raid firmware drives don't
appear to do retries in firmware.
But
James Bottomley wrote:
For the MD case, this is what REQ_FAILFAST is for.
I cannot find where SCSI honours that flag. James?
And for that matter, even when I patch SCSI so that it *does* honour it,
I don't actually see the flag making it into the SCSI layer from above.
And I don't see
Mark Lord wrote:
James Bottomley wrote:
For the MD case, this is what REQ_FAILFAST is for.
I cannot find where SCSI honours that flag. James?
Scratch that thought.. SCSI honours it in scsi_end_request().
But I'm not certain that the block layer handles it correctly,
at least not in the
On Wed, 2007-01-31 at 10:13 -0500, Mark Lord wrote:
James Bottomley wrote:
For the MD case, this is what REQ_FAILFAST is for.
I cannot find where SCSI honours that flag. James?
Er, it's in scsi_error.c:scsi_decide_disposition():
maybe_retry:
/* we requeue for retry because
Ric Wheeler wrote:
Jeff Garzik wrote:
Mark Lord wrote:
Eric D. Mudama wrote:
Actually, it's possibly worse, since each failure in libata will
generate 3-4 retries. With existing ATA error recovery in the
drives, that's about 3 seconds per retry on average, or 12 seconds
per failure.
Douglas Gilbert wrote:
Ric,
Both ATA (ATA8-ACS) and SCSI (SBC-3) have recently added
command support to flag a block as uncorrectable. There
is no need to send bad long data to it and suppress the
disk's automatic re-allocation logic.
That'll be useful in a couple of years, once drives that
Alan wrote:
When libata reports a MEDIUM_ERROR to us, we *know* it's non-recoverable,
as the drive itself has already done internal retries (libata uses the
with retry ATA opcodes for this).
This depends on the firmware. Some of the raid firmware drives don't
appear to do retries in
Alan wrote:
When libata reports a MEDIUM_ERROR to us, we *know* it's non-recoverable,
as the drive itself has already done internal retries (libata uses the
with retry ATA opcodes for this).
This depends on the firmware. Some of the raid firmware drives don't
appear to do retries in firmware.
On Wed, 2007-01-31 at 12:57 -0500, Mark Lord wrote:
Alan wrote:
When libata reports a MEDIUM_ERROR to us, we *know* it's non-recoverable,
as the drive itself has already done internal retries (libata uses the
with retry ATA opcodes for this).
This depends on the firmware. Some of the
James Bottomley wrote:
On Wed, 2007-01-31 at 12:57 -0500, Mark Lord wrote:
Alan wrote:
When libata reports a MEDIUM_ERROR to us, we *know* it's non-recoverable,
as the drive itself has already done internal retries (libata uses the
with retry ATA opcodes for this).
This depends on the
Robert Hancock wrote:
http://marc.theaimsgroup.com/?t=11692262122
It looks like Tejun's patch essentially does the same thing as mine with
the addition of the control from userspace. There is one exception
though, my patch also does the stop on removal of the SCSI disk (i.e.
writing 1
Stefan Richter wrote:
Robert Hancock wrote:
http://marc.theaimsgroup.com/?t=11692262122
It looks like Tejun's patch essentially does the same thing as mine with
the addition of the control from userspace. There is one exception
though, my patch also does the stop on removal of the SCSI
Hi,
Patro, Sumant:
What I see in the log is cmd timeout(s) and is not related to the patch.
Ouch.
Any ideas what causes my problem? It's a regression; I tested Ubuntu
Dapper and Edgy install CDs, and it's not worked since the latter.
I can pinpoint the change that triggers the problem more
36 matches
Mail list logo
