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.
Reviewed-by: Jeremy Linton jlin...@tributary.com
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
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?
-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
-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 has
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
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 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 for
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 jlin
-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 this
-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 treat
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. Why
-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
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.
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 the
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 =
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/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
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-scsim=136104139102048w=2
With that patch you might only
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 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/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 for
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 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.
Well
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 bit
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 (unless i'm
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
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 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 will
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_flush_io_context() call in lpfc_device_reset_handler
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
as a IOSTAT_LOCAL_REJECT as there isn't a FCP RSP associated with the
error.
Signed-off-by: Jeremy Linton jlin...@tributary.com
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
-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 first
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
-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 my testing
-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
-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-
-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 versions to the existing ioctl. This should
-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 went
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
-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
-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/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
in case...
Signed-off-by: Jeremy Linton jlin...@tributary.com
---
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
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
SG_SCSI_RESET_DEVICE_ONLY. While leaving the existing operations alone.
Just in case...
Signed-off-by: Jeremy Linton jlin...@tributary.com
---
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/drivers/scsi/scsi_error.c
-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
-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
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 correct problems on a specific I_T_L
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 a
[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 would like to strongly
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-scsim=117392208211297w=2
I just read the thread.. I didn't see any strange retries
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:
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
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
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
other transports have something
62 matches
Mail list logo
