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
[PATCH 1/2] libiscsi: Add a missing break statement
From: Adheer Chandravanshi adheer.chandravan...@qlogic.com Signed-off-by: Adheer Chandravanshi adheer.chandravan...@qlogic.com Signed-off-by: Vikas Chaudhary vikas.chaudh...@qlogic.com --- 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
[PATCH 0/2] libiscsi: Updates for scsi misc branch
From: Adheer Chandravanshi adheer.chandravan...@qlogic.com 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 2/2] libiscsi: Add missing prints for session and connection sysfs attrs
From: Adheer Chandravanshi adheer.chandravan...@qlogic.com Signed-off-by: Adheer Chandravanshi adheer.chandravan...@qlogic.com Signed-off-by: Vikas Chaudhary vikas.chaudh...@qlogic.com --- 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
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
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: [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: [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 emi...@redhat.com 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-scsim=129702506514742w=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: [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 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: [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 jo...@logfs.org 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 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 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 0/3] [SCSI] megaraid: Remove local (struct pci_dev) pdev's
On Tue, Jul 9, 2013 at 11:10 PM, James Bottomley
james.bottom...@hansenpartnership.com 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 0/2] libiscsi: Updates for scsi misc branch
On 07/22/2013 06:46 AM, adheer.chandravan...@qlogic.com wrote: From: Adheer Chandravanshi adheer.chandravan...@qlogic.com 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 micha...@cs.wisc.edu -- 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
