Re: [PATCH 0/2] libiscsi: Updates for scsi "misc" branch
On 07/22/2013 06:46 AM, adheer.chandravan...@qlogic.com wrote: > From: Adheer Chandravanshi > > James, > > Please apply the following patches to the scsi tree at your earliest > convenience. > In the future could you send a link to the patches that a patchset depends on? It helps in reviewing them. > Adheer Chandravanshi (2): > libiscsi: Add a missing break statement > libiscsi: Add missing prints for session and connection sysfs attrs > Patches look ok. Reviewed-by: Mike Christie -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] [SCSI] megaraid: Remove local (struct pci_dev) pdev's
On Tue, Jul 9, 2013 at 11:10 PM, James Bottomley
wrote:
> On Tue, 2013-07-09 at 15:12 -0700, adam radford wrote:
>> On Tue, Jul 9, 2013 at 2:18 PM, James Bottomley
>> > Adam, you do drive by coding on this for LSI ... ack or reject, please.
>
>> I have just now located my box of MegaRAID Parallel SCSI controllers.
>> I will review and test the patch series from Myron and respond by next
>> Monday.
>
> Thanks,
>
> James
>
>
Unfortunately my box of MegaRAID Parallel SCSI controllers only
contains only cards intended for megaraid_mbox.c (I tested all 20 of
them),
and does not contain any of the following really old Symbios based
megaraid cards:
static struct pci_device_id megaraid_pci_tbl[] = {
{PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_AMI_MEGARAID,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
{PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_AMI_MEGARAID2,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_AMI_MEGARAID3,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
{0,}
};
which I had located previously before the company headquarters moved.
I cannot currently locate any of the above 3 controllers anywhere at
LSI headquarters after an exhaustive search, so I cannot test the
patches to megaraid.c from Myron @ RedHat.
Myron, do you actually have the hardware and have you tested the
patches yourself ?
-Adam
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] [SCSI] Enhanced sense and Unit Attention handling
On Mon, 2013-07-22 at 15:31 +, James Bottomley wrote: > Ping on this, please. > > I have another possible consumer of this infrastructure, when it's > ready, which is the SCSI RAID drivers. We've been getting complaints > that there's no event we get from them when a RAID system goes from > online -> degraded which should be the sysadmin's cue to go in and > replace the disk (well, this isn't quite true, a lot come with > proprietary monitoring daemons which do this, but they're pretty unique > per controller). > > I was thinking we might resurrect the orphaned raid_class.c to do this > and give a universally displayable but rudimentary view of the topology > and health of the device and add an easy hook for RAID events. > > James > I'm testing a v4 version of these patches, which address your earlier comments. I'm still working on the code to suppress the duplicate REPORTED LUNS DATA HAS CHANGED unit attentions from multiple LUNs. As I mentioned in my earlier mail, doing this with the expected_cc_ua mechanism is imperfect, because SCSI-3 devices will stop reporting it when one of the LUNs on the target *receives* a REPORT LUNs command, and it is difficult to know when this happens. I'm trying out clearing the flag before the SCSI scan code issues a REPORT LUNs, that might be good enough. (It doesn't handle someone from sending this command through the sg driver, though.) Will post the v4 soon. -Ewan -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND 0/1] AHCI: Optimize interrupt processing
On Mon, 2013-07-22 at 17:03 +0200, Alexander Gordeev wrote: > On Fri, Jul 19, 2013 at 09:56:02PM -0700, Nicholas A. Bellinger wrote: > > On Fri, 2013-07-19 at 14:01 -0700, Nicholas A. Bellinger wrote: > > OK, after further investigation the root cause is a actually a missing > > bio->bio_end_io() -> bio_copy_kern_endio() -> bio_put() from the > > blk_end_sync_rq() callback path that scsi-mq REQ_TYPE_BLOCK_PC is > > currently using. > > Yes, missing bio_copy_kern_endio() callback is exactly the reason I > turned to blk_mq_execute_rq() initially. I should have been more > specific on this :| > > I will try Mike's and your other change, hopefully soon (sorry, > constantly getting distracted). > Np. FYI, you'll want to use the latest commit e7827b351 HEAD from target-pending/scsi-mq, which now has functioning scsi-generic support. Also, your scsi_times_out patch from earlier has not been included just yet, but that should be the only extra patch you need to apply in order to get scsi-mq enabled libata/ata_piix running. --nab -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/4] [SCSI] sg: fix race condition in sg_open
On Mon, 22 July 2013 12:40:29 +0800, Vaughan Cao wrote: > > There is a race when open sg with O_EXCL flag. Also a race may happen between > sg_open and sg_remove. > > Changes from v4: > * [3/4] use ERR_PTR series instead of adding another parameter in sg_add_sfp > * [4/4] fix conflict for cherry-pick from v3. > > Changes from v3: > * release o_sem in sg_release(), not in sg_remove_sfp(). > * not set exclude with sfd_lock held. > > Vaughan Cao (4): > [SCSI] sg: use rwsem to solve race during exclusive open > [SCSI] sg: no need sg_open_exclusive_lock > [SCSI] sg: checking sdp->detached isn't protected when open > [SCSI] sg: push file descriptor list locking down to per-device > locking > > drivers/scsi/sg.c | 178 > +- > 1 file changed, 83 insertions(+), 95 deletions(-) Patchset looks good to me, although I didn't test it on hardware yet. Signed-off-by: Joern Engel James, care to pick this up? Jörn -- Good warriors cause others to come to them and do not go to others. -- Sun Tzu -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/4] [SCSI] sg: checking sdp->detached isn't protected when open
On Sat, 20 July 2013 15:53:16 +0800, Xitao Cao wrote: > > Thanks for your comment. Do I need to update it and resend? Yes, please. Jörn -- When people work hard for you for a pat on the back, you've got to give them that pat. -- Robert Heinlein -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-2013-discuss] [ATTEND] scsi-mq prototype discussion
On Fri, Jul 19 2013, Ric Wheeler wrote: > down the work items ahead of a real mainline push is high on > priority list for discussion. > > The parties to be included in such a discussion are: > > - Jens Axboe (blk-mq author) > - James Bottomley (scsi maintainer) > - Christoph Hellwig (scsi) > - Martin Petersen (scsi) > - Tejun Heo (block + libata) > - Hannes Reinecke (scsi error recovery) > - Kent Overstreet (block, per-cpu ida) > - Stephen Cameron (scsi-over-pcie driver) > - Andrew Vasquez (qla2xxx LLD) > - James Smart (lpfc LLD) > >>>Isn't this something that should have been discussed at the storage > >>>mini-summit a few months ago? > >>The scsi-mq prototype, along with blk-mq (in it's current form) did not > >>exist a few short months ago. ;) > >> > >>> It seems very specific to one subsystem to be a kernel summit topic, > >>>don't you think? > >>It's no more subsystem specific than half of the other proposals so far, > >>and given it's reach across multiple subsystems (block, scsi, target), > >>and the amount of off-list interest on the topic, I think it would make > >>a good candidate for discussion. > >> > >And it'll open up new approaches which previously were dismissed, > >like re-implementing multipathing on top of scsi-mq, giving us the > >single scsi device like other UNIX systems. > > > >Also I do think there's quite some synergy to be had, as with blk-mq > >we could nail each queue to a processor, which would eliminate the > >need for locking. > >Which could be useful for other subsystems, too. > Lets start with discussing this on the list, please, and then see where > we go from there ... > > >>>Yes, the discussion is beginning to make it's way to the list. I've > >>>mostly been waiting for blk-mq to get a wider review before taking the > >>>early scsi-mq prototype driver to a larger public audience. > >>> > >>>Primarily, I'm now reaching out to the people most effected by existing > >>>scsi_request_fn() based performance limitations. Most of them have > >>>abandoned existing scsi_request_fn() based logic in favor of raw block > >>>make_request() based drivers, and are now estimating the amount of > >>>effort to move to an scsi-mq based approach. > >>> > >>>Regardless, as the prototype progresses over the next months, having a > >>>face-to-face discussion with the key parties in the room would be very > >>>helpful given the large amount of effort involved to actually make this > >>>type of generational shift in SCSI actually happen. > >>There's a certain amount of overlap with the aio/O_DIRECT work as well. > >>But if it's not a general session, could always be a BOF or something. > >> > >>I'll second the argument that most technical topics probably DO belong > >>in a topic related workshop. But that leaves us with basically only > >>process related topics at KS, I don't think it hurts to have a bit of > >>tech meat on the bone too. At least I personally miss that part of KS > >>from years gone by. > >Heh well, given that most of the block mq discussions at LSF have been > >you saying you really should get around to cleaning up and posting the > >code, you'll understand my wanting to see that happen first ... > > > >I suppose we could try to run a storage workshop within KS, but I think > >most of the mini summit slots have already gone. There's also plumbers > >if all slots are gone (I would say that, being biased and on the > >programme committee) Ric is running the storage and Filesystems MC > > > >http://www.linuxplumbersconf.org/2013/ocw/events/LPC2013/tracks/159 > > > >James > > > > And we still are looking for suggested topics - it would be great to have > the multi-queue work at plumbers. > > You can post a proposal for it (or other topics) here: > > http://www.linuxplumbersconf.org/2013/ocw/events/LPC2013/proposals FWIW, I can't make Plumbers this year, unfortunately. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] [SCSI] Enhanced sense and Unit Attention handling
On Wed, 2013-06-19 at 13:42 -0400, Ewan D. Milne wrote: > From: "Ewan D. Milne" > > This patch set adds changes to the SCSI mid-layer, sysfs and scsi_debug > to provide enhanced support for Unit Attention conditions, as well as > detection of a unit attention queue overflow condition and the ability > for drivers to report sense data outside of normal command completion. > > There was some discussion about this a couple of years ago on the linux-scsi > mailing list: http://marc.info/?l=linux-scsi&m=129702506514742&w=2 > Although one approach is to send all SCSI sense data to a userspace daemon > for processing, this patch set does not take that approach due to the > difficulty in reliably delivering all of the data. An interesting UA > condition might not be delivered due to a flood of media errors, for example. > > 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 mechanism is used to avoid generating uevents at > too high a rate, and to coalesce multiple UAs reported by LUNs on the > same target for a REPORTED LUNS DATA HAS CHANGED sense code. > > The changes are enabled by a new kernel config option CONFIG_SCSI_ENHANCED_UA. > If this config option is not used, no new uevents are generated. There are > some changes to kernel logging messages if CONFIG_SCSI_ENHANCED_UA is enabled, > because the existing messages explicitly stated that the kernel did not do > anything with the information. > > Note that checkpatch is reporting errors on patch 5/6 relating to macros > in scsi_sysfs.c -- I believe these errors are incorrect and have sent a > message to the checkpatch maintainer. The macros were derived from > existing ones already in the file. > > Changes made since earlier v2 version: > >- Remove patch 1/8 "Generate uevent on sd capacity change" >- Remove patch 8/8 "Streamline detection of FM/EOM/ILI status" >- Changed scsi_debug to not generate UA on INQUIRY or REPORT_LUNS >- Changed scsi_debug to only report UA queue overflow condition > if dsense=1, as descriptor format sense data is needed > > Changes made since earlier RFC version: > >- Remove patch 1/9 "Detect overflow of sense data buffer" > Some scsi_debug changes in this patch were moved to patch 7/8 >- Corrected Kconfig help text >- Change name of "sdev_evt_thread" to "sdev_evt_work" >- Change name of "starget_evt_thread" to "starget_evt_work" >- Pull code out of scsi_check_sense() that handles UAs into > an exported function so that drivers can report conditions > received asynchronously > > Thanks to everyone for the comments on this patch series. > > Ewan D. Milne (6): > [SCSI] Add a kernel config option for enhanced Unit Attention support > [SCSI] Rename scsi_evt_xxx to sdev_evt_xxx and scsi_event to > sdev_event > [SCSI] Add support for scsi_target events > [SCSI] Generate uevents for certain Unit Attention codes > [SCSI] Add sysfs support for enhanced Unit Attention handling > [SCSI] Add sense and Unit Attention generation to scsi_debug Ping on this, please. I have another possible consumer of this infrastructure, when it's ready, which is the SCSI RAID drivers. We've been getting complaints that there's no event we get from them when a RAID system goes from online -> degraded which should be the sysadmin's cue to go in and replace the disk (well, this isn't quite true, a lot come with proprietary monitoring daemons which do this, but they're pretty unique per controller). I was thinking we might resurrect the orphaned raid_class.c to do this and give a universally displayable but rudimentary view of the topology and health of the device and add an easy hook for RAID events. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND 0/1] AHCI: Optimize interrupt processing
On Fri, Jul 19, 2013 at 09:56:02PM -0700, Nicholas A. Bellinger wrote: > On Fri, 2013-07-19 at 14:01 -0700, Nicholas A. Bellinger wrote: > OK, after further investigation the root cause is a actually a missing > bio->bio_end_io() -> bio_copy_kern_endio() -> bio_put() from the > blk_end_sync_rq() callback path that scsi-mq REQ_TYPE_BLOCK_PC is > currently using. Yes, missing bio_copy_kern_endio() callback is exactly the reason I turned to blk_mq_execute_rq() initially. I should have been more specific on this :| I will try Mike's and your other change, hopefully soon (sorry, constantly getting distracted). > Including the following patch into the scsi-mq working branch now, and > reverting the libata dma_alignment=0x03 hack. -- Regards, Alexander Gordeev agord...@redhat.com -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SAS Management Protocol (SMP) on Windows
On 07/22/2013 03:43 PM, Douglas Gilbert wrote: > On 13-07-22 04:26 AM, Hugh Chin wrote: >> I'm developing SMP application by Python. I've ran it on Linux, it works >> fine. But now I have to run it on Windows. Of course, it didn't work. >> >> So far I know that Windows seems doesn't have bsg driver. But I'm not >> sure. >> I want to know is there any way can run SMP application on Windows? >> >> My English is poor, so if you had something misunderstanding. Please >> let me >> know. > > My smp_utils package is written for Linux and ported to > FreeBSD using the latter's CAM interface recently expanded > to pass-through SMP commands. I'm not aware of any such > generic SMP pass-through for Windows but I'd be happy > to be corrected. Agree, there is no such generic SMP pass-through interface for Windows, Different Vendor offer their SMP IOCTL interface there own. You can checkout from your hardware vendor. > > Apart from that, this is probably the wrong list to be > discussing this subject. Agree. Jack > > Doug Gilbert > > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SAS Management Protocol (SMP) on Windows
On 13-07-22 04:26 AM, Hugh Chin wrote: I'm developing SMP application by Python. I've ran it on Linux, it works fine. But now I have to run it on Windows. Of course, it didn't work. So far I know that Windows seems doesn't have bsg driver. But I'm not sure. I want to know is there any way can run SMP application on Windows? My English is poor, so if you had something misunderstanding. Please let me know. My smp_utils package is written for Linux and ported to FreeBSD using the latter's CAM interface recently expanded to pass-through SMP commands. I'm not aware of any such generic SMP pass-through for Windows but I'd be happy to be corrected. Apart from that, this is probably the wrong list to be discussing this subject. Doug Gilbert -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] libiscsi: Add missing prints for session and connection sysfs attrs
From: Adheer Chandravanshi Signed-off-by: Adheer Chandravanshi Signed-off-by: Vikas Chaudhary --- drivers/scsi/libiscsi.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c index afc6c3f..f757617 100644 --- a/drivers/scsi/libiscsi.c +++ b/drivers/scsi/libiscsi.c @@ -3312,6 +3312,9 @@ int iscsi_session_get_param(struct iscsi_cls_session *cls_session, case ISCSI_PARAM_DATASEQ_INORDER_EN: len = sprintf(buf, "%d\n", session->dataseq_inorder_en); break; + case ISCSI_PARAM_DEF_TASKMGMT_TMO: + len = sprintf(buf, "%d\n", session->def_taskmgmt_tmo); + break; case ISCSI_PARAM_ERL: len = sprintf(buf, "%d\n", session->erl); break; @@ -3522,6 +3525,9 @@ int iscsi_conn_get_param(struct iscsi_cls_conn *cls_conn, case ISCSI_PARAM_IPV6_TC: len = sprintf(buf, "%u\n", conn->ipv6_traffic_class); break; + case ISCSI_PARAM_IPV6_FLOW_LABEL: + len = sprintf(buf, "%u\n", conn->ipv6_flow_label); + break; case ISCSI_PARAM_IS_FW_ASSIGNED_IPV6: len = sprintf(buf, "%u\n", conn->is_fw_assigned_ipv6); break; -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] libiscsi: Updates for scsi "misc" branch
From: Adheer Chandravanshi James, Please apply the following patches to the scsi tree at your earliest convenience. Adheer Chandravanshi (2): libiscsi: Add a missing break statement libiscsi: Add missing prints for session and connection sysfs attrs Thanks, Adheer -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] libiscsi: Add a missing break statement
From: Adheer Chandravanshi Signed-off-by: Adheer Chandravanshi Signed-off-by: Vikas Chaudhary --- drivers/scsi/libiscsi.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c index 86153e0..afc6c3f 100644 --- a/drivers/scsi/libiscsi.c +++ b/drivers/scsi/libiscsi.c @@ -3350,6 +3350,7 @@ int iscsi_session_get_param(struct iscsi_cls_session *cls_session, break; case ISCSI_PARAM_BOOT_TARGET: len = sprintf(buf, "%s\n", session->boot_target); + break; case ISCSI_PARAM_AUTO_SND_TGT_DISABLE: len = sprintf(buf, "%u\n", session->auto_snd_tgt_disable); break; -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
SAS Management Protocol (SMP) on Windows
I'm developing SMP application by Python. I've ran it on Linux, it works fine. But now I have to run it on Windows. Of course, it didn't work. So far I know that Windows seems doesn't have bsg driver. But I'm not sure. I want to know is there any way can run SMP application on Windows? My English is poor, so if you had something misunderstanding. Please let me know. Thanks a lot. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
