Markus Naeher [EMAIL PROTECTED] wrote:
The missing disk is always the first one (LUN 000). I have tested this by
changing
the order of the disks on ESS 2.
I have also repeated the test scenario with only one path per disk.
In this testcase, I have divided the ESS's on the two Adapters
James Bottomley [EMAIL PROTECTED] wrote:
On Fri, 2008-02-01 at 14:00 -0600, Mike Christie wrote:
Chandra Seetharaman wrote:
@@ -1445,9 +1479,24 @@ static void scsi_kill_request(struct req
static void scsi_softirq_done(struct request *rq)
{
struct scsi_cmnd *cmd =
Mike Christie [EMAIL PROTECTED] wrote:
When IO is sent to a path that cannot execute IO optimally, the scsi hw
handler hook for sense processing (see rdac_check_sense in [PATCH 8/9]
scsi_dh: add lsi rdac device handler and the scsi_error.c hook in in
scsi_dh: add skeleton for SCSI Device
James Bottomley [EMAIL PROTECTED] wrote:
On Wed, 2008-01-23 at 16:32 -0800, Chandra Seetharaman wrote:
Subject: scsi_dh: Add support for SDEV_PASSIVE
From: Chandra Seetharaman [EMAIL PROTECTED]
This patch adds a new device state SDEV_PASSIVE, to correspond to the
passive side
Mike Christie [EMAIL PROTECTED] wrote:
Chandra Seetharaman wrote:
* mainly associated with tapes and returned SUCCESS.
Index: linux-2.6.24-rc8/drivers/scsi/scsi_sysfs.c
===
---
Matthew Wilcox [EMAIL PROTECTED] wrote:
The only problem is ... we never set the FE_ISTAT1 bit. Mike tells me
that when he sets it, it makes his error recovery work.
I think we need a patch somewhat along these lines:
{PCI_DEVICE_ID_LSI_53C1010_66, 0xff, 1010-66, 6, 31, 7, 8,
Copying this mail to linux-scsi and Ccing Andrew Vasquez to possibly
provide input on the Qlogic behavior.
Chandra Seetharaman [EMAIL PROTECTED] wrote:
On Thu, 2007-07-12 at 18:35 -0700, Brian De Wolf wrote:
Hello All,
I'm not sure if this is the right place for this, but it seems to be
James Bottomley [EMAIL PROTECTED] wrote:
A proposal to display the correct form of the LUN would be useful if you
wish to make it? ... The problem is really that SAM specifies a
possible 4 level structure with 4 possible address methods per level.
The well known LUNs should be simple; there
Alan Stern [EMAIL PROTECTED] wrote:
The conundrum I'm facing is how to make sure that when scsi_remove_host
returns, the mid-layer is no longer sending anything to the host. Sure,
no new commands will be issued once the state is set to DEL (or
DEL_RECOVERY). But what about commands/resets
Alan Stern [EMAIL PROTECTED] wrote:
On Wed, 7 Sep 2005, Luben Tuikov wrote:
On 09/07/05 14:27, Alan Stern wrote:
I'm going to argue strongly about this. scsi_remove_host should _not_
wait for error recovery to complete -- to do so will invite deadlocks.
(Suppose the error
Luben Tuikov [EMAIL PROTECTED] wrote:
On 08/19/05 15:38, Patrick Mansfield wrote:
The eh_timed_out + eh_strategy_handler is actually pretty perfect,
and _complete_, for any application and purpose in recovering a
LU/device/host (in that order ;-) ).
The two problems I see with the hook
Luben Tuikov [EMAIL PROTECTED] wrote:
On 08/07/05 17:57, James Bottomley wrote:
Alan Stern wrote:
The only resource that matters for this discussion is associated with the
LLD itself, not with any of its hosts: the host template. Once the SCSI
core has released all references to the
James Bottomley [EMAIL PROTECTED] wrote:
On Sun, 2005-08-07 at 14:43 -0400, Alan Stern wrote:
What host device release method? scsi_host_template-release is marked
OBSOLETE and for use only with old-style drivers. scsi_host_dev_release
Alan Stern [EMAIL PROTECTED] wrote:
Here you are wrong. In fact the core makes no such guarantees. It _will_
try to enter the host (for things like telling disk drives to flush
their caches) for as long as it retains a reference to the host structure.
Well post scsi_remove_host returning no
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
Greg,
I will add the same comment to the bug.
Did this work on a previous version of the kernel? Just checking to
understand if your connectivity to the storage unit or the unit itself
could be an issue.
If appears we are receiving timeouts, but on abort the qla is indicating
that the IO has
Tejun Heo [EMAIL PROTECTED] wrote:
Jens Axboe wrote:
On Wed, Apr 06 2005, Arjan van de Ven wrote:
@@ -324,6 +334,7 @@
issue_flush_fn *issue_flush_fn;
prepare_flush_fn*prepare_flush_fn;
end_flush_fn*end_flush_fn;
+ release_queue_data_fn
Here is a refresh of an update to the status_byte macro.
Previous mail
http://marc.theaimsgroup.com/?l=linux-scsim=110322214824566w=2
-andmike
--
Michael Anderson
[EMAIL PROTECTED]
Add TASK_ABORTED and ACA_ACTIVE to status_byte macro.
Signed-off-by: Mike Anderson [EMAIL PROTECTED]
---
linux
Greg KH [EMAIL PROTECTED] wrote:
On Wed, Jan 19, 2005 at 06:13:57PM +0100, Christoph Hellwig wrote:
I think the hardware_version, firmware_version, rom_version and
driver_version don't belong into the FC transport class, there's
nothign specific to FC or even SCSI specific in them.
Then
this
into the proper device to reserve. I guess it is up to the caller of
your service to handle this case correct??
If this not any clearer than my last mail I will just wait to see the code
:-).
Thanks,
-Mike
Doug Ledford [[EMAIL PROTECTED]] wrote:
To: Mike Anderson [EMAIL PROTECTED
The hardware error code is used to mainly map failures of servo , diagnostics,
defect list, etc that are un-recoverable.
The error you are having appears to be related to the servo. If it is only
over certain areas of the disk it could be do to servo read errors, or ??(drive
electronics are not
21 matches
Mail list logo
