Hello,
So, looking at this, I don't see how it supports the algorithm I've
been using
for years. For that algorithm to successfully migrate PRs across multiple paths
on a single machine without affecting other possible users (who may legitimately
have PR'ed the same device) I need PR_IN SA
On 7/20/2014 4:54 PM, joystick wrote:
> So what happens when the disk tries to write it to the platter and
> discovers that there is a media error on that sector? (suppose relocation
> does not happen ; maybe sectors exhausted) Does Linux receive the write
> error upon the next flush it issues?
On 5/24/2013 5:57 AM, Hannes Reinecke wrote:
> Which leads to the interesting question: What happens with the actual
> command once eh_abort_handler returns?
Well, eventually it ends up on the done_q and gets returned up the
stack via
flush_done_q(). But that wasn't what you were asking?
On 5/27/2013 8:32 PM, Baruch Even wrote:
> necessary but the command itself if it is already actively handled
> continues in its path. The abort only cancels those commands that are in
> the queue and if there really was a problem and the disk is engaging in
> error recovery of its own you'll just
On 8/30/2013 7:47 AM, Douglas Gilbert wrote:
> I proposed the following patch some time back to give the user space finer
> resolution on resets with the option of stopping the escalation but it has
> gone nowhere: http://marc.info/?l=linux-scsi&m=136104139102048&w=2
>
> With that patch you might
On 9/6/2013 11:22 AM, James Smart wrote:
> Fixed issue of task management commands having a fixed timeout
I'm surprised about this change, since it appears a number of issues in
the
send_taskmgmt() still exist that keep it from handling task management
failures correctly. It also continue
On 9/8/2013 8:59 AM, James Smart wrote:
> The other issue - we seem to have missed your prior post. I'll look into it
> shortly.
Thanks,
Those patches were the result of various error injection test cases we
were
performing. The ones that come to mind were, hung sequences, TM rejects,
On 9/2/2013 6:58 AM, Hannes Reinecke wrote:
> +static int scsi_eh_action(struct scsi_cmnd *scmd, int rtn) +{ + static
> unsigned char tur_command[6] = {TEST_UNIT_READY, 0, 0, 0, 0, 0}; + + if
> (scmd->request->cmd_type != REQ_TYPE_BLOCK_PC) { +struct
> scsi_driver
> *sdrv = scsi
On 9/24/2013 12:39 AM, Hannes Reinecke wrote:
> My drives support 'report opcodes', and report that write same is
> supported: ... 93 16Write same(16) ...
>
> but no support for page 'b0'. And yes, these are real SAS drives.
So the question is, how many devices get t
On 1/26/2015 6:11 PM, Seymour, Shane M wrote:
> I was wondering if anyone had any feedback or had any chance to review the
> changes?
Per the other discussion about having the same stat format forever. It
seems to
me that you might want to preemptively add a few additional counters.
On 12/3/2012 1:15 AM, Hannes Reinecke wrote:
> Well, looking at QLogic and Emulex both emulate a bus reset with a loop
> over each target and invoke a target reset there. I somewhat fail to see
> the rationale behind it, other than emulating the bus reset behaviour on
> SPI.
It is actually
On 12/7/2012 1:58 PM, Chad Dupuis wrote:
> Also, are there certain port types we wouldn't want to send this reset to
> such as tape?
AFAIK, for tape it shouldn't cause any more harm than the target reset
which
happens immediately before it. This patch is infinitely better than the
previo
On 12/7/2012 3:20 PM, Mike Christie wrote:
> On 12/07/2012 03:05 PM, Jeremy Linton wrote:
>> That said, its far from perfect. The code (as I understand it) isn't
>> differentiating between isolating the failure, or bringing out the big
>> hammer in an attempt to corr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/24/2013 8:38 AM, Bart Van Assche wrote:
> Let me ask this another way. SAN users expect that the LUN list at the
> initiator side gets updated automatically after a SAN configuration change.
> How should a SAN system communicate to a SCSI initia
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/28/2013 9:44 AM, Bart Van Assche wrote:
> when using Fibre Channel as transport layer. I'm looking for a solution
> that also works with other SCSI transports, e.g. iSCSI and SRP.
Doesn't iSCSI have a SNS server you can subscribe to that
ds some new values like
"SG_SCSI_RESET_DEVICE_ONLY". While leaving the existing operations alone.
Just in case...
Signed-off-by: Jeremy Linton
---
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index c1b05a8..6f05bc2 100644
--- a/drivers/scsi/scsi_error.c
+++ b/driv
ut.
Just in case...
Signed-off-by: Jeremy Linton
---
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index c1b05a8..b249c2f 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -572,24 +572,25 @@ static int scsi_try_host_reset(struct scsi_cmnd *scmd)
On 2/12/2013 2:57 PM, Elliott, Robert (Server Storage) wrote:
> Ideally the device driver for the SCSI initiator port would report those
> attributes, and higher level code would combine them with support
> information from the device server (REPORT SUPPORTED TMF command, REPORT
> SUPPORTED OPCODES
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/13/2013 7:06 AM, Hannes Reinecke wrote:
> But unfortunately it failed the reality check; of my zoo of storage arrays
> only NetApp OnTap 8.X and HP P2000 supports the REPORT SUPPORTED TASK
> MANAGEMENT FUNCTIONS command. None of the others (HP EV
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/13/2013 9:06 AM, Hannes Reinecke wrote:
> So add a new flag 'support_64bit_luns' to the scsi host and modify report
> lun scan to not check for max_luns during scanning if that flag is set.
> This will get rid of the
Along these lines, I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/13/2013 9:38 PM, James Bottomley wrote:
> Yes. The two functions are simple transforms ensuring that we can pack up
> to two levels of luns into a u32 whatever address method is used. At the
> time it was done, no array or other extant system we
On 2/13/2013 8:43 PM, Michael Christie wrote:
> For the case where report supported TMFs is not supported can we just have
> the LLD return some new return code from the eh callback when it gets
> FUNCTION_REJECTED. scsi-ml would then clear the eh_*_ok bit, so at least it
> would not be called a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/13/2013 9:37 PM, James Bottomley wrote:
> What advantage does this have over setting max_lun to ~0?
Is it possible the adapters have LUN resource limits as well as ID
limits? In
those cases it would be nice to notify the user that LUNs
On 2/14/2013 4:04 PM, Elliott, Robert (Server Storage) wrote:
> Like James notes, LUNs should generally be treated as opaque values.
I agree, except there is a max host lun check based on a decoded lun
value. Not
really sure why its there other than maybe some of the HBA's have resource
i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/14/2013 4:04 PM, Elliott, Robert (Server Storage) wrote:
> Like James notes, LUNs should generally be treated as opaque values.
Maybe another issue to consider is how they are being displayed in
userland.
A device with two luns using one
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/14/2013 5:42 PM, Elliott, Robert (Server Storage) wrote:
> Each logical unit is independent and is allowed to be different.
I was actually just thinking about the target reset and IT reset flags.
Two
flags which affect the I_T not the I_
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/13/2013 9:37 PM, James Bottomley wrote:
> What advantage does this have over setting max_lun to ~0?
Actually, after having all those other discussions. I've come to see the
elegance in this suggestion.
-BEGIN PGP SIGNATURE-
Ver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/15/2013 1:39 PM, Douglas Gilbert wrote:
> Further to the thread titled: "[PATCH] SG_SCSI_RESET ioctl should only
> perform requested operation" by Jeremy Linton a patch is presented that
> adds "no_escalate" version
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tested-by: Jeremy Linton jlin...@tributary.com
I tested this patch in an environment where the lun and target reset is
"failing" because the target device is misbehaving.
This patch appears to work as advertised.
That said, I changed
The lpfc_send_taskmgmt() routine fails to check the return IOCB from the
firmware. This means that all taskmgmt functions appear to complete even when
they are failing due to device failures, or task mgmt errors.
This patch corrects this by checking the iocb.ulpStatus after the command has
complet
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/1/2013 9:06 AM, James Bottomley wrote:
>> The results were "interesting", there are some really strange things that
>> happen in some of the LLD error paths. Its obvious that error injection
>> is not part of testing many of them, and what at fir
IOSTAT_LOCAL_REJECT as there isn't a FCP RSP associated with the
error.
Signed-off-by: Jeremy Linton
diff --git a/drivers/scsi/lpfc/lpfc_scsi.c b/drivers/scsi/lpfc/lpfc_scsi.c
index 60e5a17..b940f04 100644
--- a/drivers/scsi/lpfc/lpfc_scsi.c
+++ b/drivers/scsi/lpfc/lpfc_scsi.c
@@ -4
LLDs.
Thanks,
Jeremy Linton
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJRN7jaAAoJEL5i86xrzcy76+sH/2u9V3GJLCgMSB2LAZDDcpAK
4t+Um2IraIJocFvylckJieoMjhfAMcsc8fJzoxvBNVb7g6NvBQZIh2IbiWhBc2Id
3
On 3/7/2013 9:47 AM, Elliott, Robert (Server Storage) wrote:
>> +int scsi_do_report_luns(struct scsi_device *sdev, int length, + * We
>> can get a UNIT ATTENTION, for example a power on/reset, so + * retry a
>> few times (like sd.c does for TEST UNIT READY). + * Experience shows
>> some
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/7/2013 11:30 AM, James Bottomley wrote:
> This also means we can't go through the linux SCSI subsystem changing
> behaviour based on what SAM says the behaviour should be. Most of what the
> SCSI subsystem does is an accumulation based on years
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/7/2013 1:19 PM, Mike Christie wrote:
> What happens for lpfc? It seems __fc_remote_port_delete ends up calling the
> fast io fail code right away and that sets FC_RPORT_FAST_FAIL_TIMEDOUT. We
> will then call lpfc_terminate_rport_io which only wil
On 3/7/2013 2:20 PM, Mike Christie wrote:
> On 03/07/2013 02:13 PM, Jeremy Linton wrote:
>> For lpfc, you never get to the code. Or rather when I was testing it, I
>> couldn't find any way to propagate an error beyond the initial
>> lpfc_reset_
On 3/15/2013 8:28 AM, Bryn M. Reeves wrote:
> On 03/15/2013 12:46 PM, Bart Van Assche wrote:
>> The SCSI EH keeps trying until all outstanding request have been
>> finished. Does lpfc_host_reset_handler() invoke scsi_done() for
>
> I don't think so (ends up calling lpfc_sli_cancel_iocbs() via
>
On 2/1/2013 11:53 AM, Ewan D. Milne wrote:
> The mechanism used is to flag when certain UA ASC/ASCQ codes are received
> that report asynchronous changes to the storage device configuration. An
> appropriate uevent is then generated for the scsi_device or scsi_target
> object. An aggregation mec
On 4/15/2013 9:13 AM, Ewan Milne wrote:
>> patch could attempt to clear the check conditions from LUNs that share
>> the I_T.
>
> I think the mid-layer will handle that automatically. If check conditions
> are reported the commands will have to be reissued.
But, not automatically (unles
On 4/23/2013 3:07 PM, James Bottomley wrote:
>
> I bet they don't; they probably obey the spec. There's a SYNC_NV bit
> which if unset (which it is in our implementation) means only sync your
> non-NV cache. For a device with all NV, that equates to nop.
Yes, linux leaves the SYNC_NV b
On 4/24/2013 7:57 AM, Paolo Bonzini wrote:
>> If the device can promise this, we don't care (and don't know) how it
>> manages that promise. It can leave the data on battery backed DRAM, can
>> archive it to flash or any other scheme that works.
>
> That's exactly the point of SYNC_NV=1.
On 5/13/2013 12:46 AM, Hannes Reinecke wrote:
> True. But and the end of the day, we _do_ want to recover the failed LUN.
> If we were to disable that faulty LUN and continue running with the others
> we won't have a chance of _ever_ recovering that one LUN.
I don't buy this. Especially f
On 5/13/2013 10:03 AM, Hannes Reinecke wrote:
> The other LUNs haven't reported an error. But how do you know whether they
> are still okay? The other LUNs might simply be idle, and no commands have
> been send to them.
Well, how about generating std inquiry against them if they are idle
On 5/13/2013 3:29 PM, Martin K. Petersen wrote:
> others. We see cases fairly often where a misbehaving target has
> confused the HBA enough that we can not bring the device back without
> doing an HBA firmware reset. Despite I/O completing successfully on
> other targets connected to the same HBA
On 1/23/2014 4:02 PM, Matthias Eble wrote:
> So: should open() fail on a reserved tape device?
Yes, this is expected behavior for tape devices, reserve 6/release is
sometimes
used by backup applications in SAN environments as an arbitration mechanism
across multiple machines.
It
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/31/2014 2:46 AM, Hannes Reinecke wrote:
> This patch make the tape always non-rewinding when SG_IO is used, thus
> allowing udev to get a proper device id for tapes.
This is wholly bad. Just because someone fires a SG ioctl at the device
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/31/2014 2:46 AM, Hannes Reinecke wrote:
> This patch make the tape always non-rewinding when SG_IO is used, thus
> allowing udev to get a proper device id for tapes.
Maybe instead of silently changing the behavior, if you just _HAVE_ to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/2/2014 5:42 AM, Hannes Reinecke wrote:
> This is due to the strictly sequential design udev has. Essentially udev
> spawns a worker for every device which gets created (= udev receives a
> uevent for).
The part I fail to see in th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/3/2014 9:06 AM, Hannes Reinecke wrote:
> That's due to udev. Udev is getting events for each device it should create
> a device node for. So for 'st' it'll get a series of events for 'stX', and
> another series of events for 'nstX'. Udev will tre
On 2/3/2014 2:51 PM, Kay Sievers wrote:
> This is not simple and not going to happen. Sibling devices in /sys cannot
> have a relationship in udev, there are only parent/child dependencies.
Ok.. so if we can't ignore all the "spare" device nodes in a given /sys
entry
for a given device. W
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/3/2014 4:15 PM, Kay Sievers wrote:
> got through quite a few changes over the years. Not sure how much the
> /dev/tape/by-*/ links are really used in the field, and what people really
> expect here.
I'm not sure they actually work that mu
On 2/10/2014 5:11 AM, Hannes Reinecke wrote:
> EVPD page 0x83 is used to uniquely identify the device. So instead of
> having each and every program issue a separate SG_IO call to retrieve this
> information it does make far more sense to display it in sysfs.
Tested-by: Jeremy Linton
On 2/11/2014 2:32 AM, Hannes Reinecke wrote:
> The problem with page 0x80 is that (per spec) it's vendor-defined. So there
> is no guarantee for it to be unique in any sense. Which makes it rather
> impractical for normal use.
>
> Hence we typically rely on page 0x83 to identify a device, be it fo
I was just looking at the REQ_SPECIAL handling and I was curious why
REQ_SPECIAL isn't being set for commands being queued by
scsi_execute_aysnc()? It is set for scsi_execute() commands.
Did someone overlook setting the flag or is this behavior intentional?
-
To unsubscribe from this list:
ents.
This patch applies against scsi_lib.c in 2.6.22.
Signed-off-by: Jeremy Linton <[EMAIL PROTECTED]>
--- linux-2.6.22/drivers/scsi/scsi_lib.c.orig 2007-07-11
19:07:06.0 -0500
+++ linux-2.6.22/drivers/scsi/scsi_lib.c2007-07-11
18:43:36.0 -0500
@@ -350,7 +350,7 @@ s
Mike Christie wrote:
I think you needed some other bits in there. See this patch
I tried just setting the bufflen first, and that still had problems.
Could you try the patch here
http://marc.info/?l=linux-scsi&m=117392208211297&w=2
I just read the thread.. I didn't see any strange retries w
[EMAIL PROTECTED] wrote:
From: Jeremy Linton <[EMAIL PROTECTED]>
Any function which use scsi_execute_async() and transfers "odd" sized data
that doesn't align correctly with the segment sizes may have its transfer
length padded out to the closest segment size.
I w
On 1/31/2014 3:29 AM, Hannes Reinecke wrote:
> Improve error handling and use standard logging functions
> instead of hand-crafted ones.
>
> @@ -182,11 +185,13 @@ static unsigned submit_rtpg(struct scsi_device *sdev,
> struct alua_dh_data *h,
> bool rtpg_ext_hdr_req)
On 3/7/2014 1:12 AM, Hannes Reinecke wrote:
> Can you file a bug with bugzilla.novell.com and assign it to me?
Thanks, its bug 867371
https://bugzilla.novell.com/show_bug.cgi?id=867371.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/15/2014 3:51 AM, Hannes Reinecke wrote:
> Add a flag 'vpd_invalid' to the SCSI device to indicate that the VPD data
> needs to be refreshed. This is required if either a manual rescan is
> triggered or if the sense code INQUIRY DATA HAS CHANGED ha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6/5/2014 10:27 AM, Boaz Harrosh wrote:
> 1. aio "scatter_gather" type io. (ie multiple pointers multiple length
> buffers that are written / read from same linear range on device) [The
> async aspect of aio can be implemented via bsg with the write
On 6/11/2014 9:33 AM, Hannes Reinecke wrote:
> _If_ we were attempting this we'd run into several issues: a) Boot will
> fail, as REPORT LUNs will return 0 LUNs (or just LUN 0). So the scanning
> code will assume everything's fine. Booting will continue, only to figure
> out that no LUNs are presen
Mark Lobo wrote:
> I had a question about disabling the block layer for SCSI devices. We
> have an embedded device, and it runs 2.4.30. We need to be able to
> support a lot of SCSI devices (in the thousands) for our device, and we
> talk to the devices via SG. We are facing a memory allocation pro
Reviewed-by: Jeremy Linton
I will test it (next week or so) when I have access to a configuration that can
test it in a meaningful way.
Thanks,
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More
On Wednesday 06 December 2006 16:50, Mike Christie wrote:
> > For iscsi, we could negotiate a value like MaxBurstLength which says
> > don't send commands with a payload larger than that size. I would guess
> > other transports have something similar. We have to check or make sure
...
> Oh yeah the
On Wednesday 06 December 2006 17:42, Jeremy Linton wrote:
> On Wednesday 06 December 2006 16:50, Mike Christie wrote:
> > > For iscsi, we could negotiate a value like MaxBurstLength which says
> > > don't send commands with a payload larger than that size. I would guess
&
So instead of adding a parameter, we can make scsi_execute_async()
decide for itself based on the SCSI command, with read/write I/Os
taking the lowest priority.
This seems like a bad idea, I can come up with a number of cases where
the priority of a request would better be optimized by a higher
68 matches
Mail list logo
