Re: [PATCH 21/21] advansys: Changes to work on parisc
On Tue, Oct 02, 2007 at 10:28:29PM -0400, Jeff Garzik wrote: Incorrect. That is highly platform specific, with many using unsigned long, since the [non-x86] platform is generally pointing to a special memory region rather than directly using an x86-like instruction. For port I/O we _do_ use int everywhere. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Resend [PATCH] qla1280: uses wrong failure path after failed pci_set_dma_mask
Hi Sorry, I got no answer, so i resend. I think there will be a wrong goto target after a failed pci_set_dma_mask. Please Check. Signed-off-by: Johannes Dickgreber [EMAIL PROTECTED] --- --- qla1280.c.orig 2007-09-19 23:32:33 +0200 +++ qla1280.c 2007-09-19 23:58:46 +0200 @@ -4298,7 +4298,7 @@ qla1280_probe_one(struct pci_dev *pdev, printk(KERN_WARNING scsi(%li): Unable to set a suitable DMA mask - aborting\n, ha-host_no); error = -ENODEV; - goto error_free_irq; + goto error_put_host; } } else dprintk(2, scsi(%li): 64 Bit PCI Addressing Enabled\n, @@ -4308,7 +4308,7 @@ qla1280_probe_one(struct pci_dev *pdev, printk(KERN_WARNING scsi(%li): Unable to set a suitable DMA mask - aborting\n, ha-host_no); error = -ENODEV; - goto error_free_irq; + goto error_put_host; } #endif Thanks tanzy - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Resend [PATCH] qla1280: wasted space in allocated pages for request and response ring
Hi Sorry I Got no answer, so i resend i think there is wasted space in allocated pages for request and response rings. The allocations are made with REQUEST_ENTRY_CNT + 1 and RESPONSE_ENTRY_CNT + 1, but they are set with 256 and 16. So we got more pages, which we dont use very much. Can you please check. Signed-off-by: Johannes Dickgreber [EMAIL PROTECTED] --- --- qla1280.h.orig 2007-09-19 23:32:42 +0200 +++ qla1280.h 2007-09-19 23:44:37 +0200 @@ -91,8 +91,8 @@ #define INVALID_HANDLE (MAX_OUTSTANDING_COMMANDS + 2) /* ISP request and response entry counts (37-65535) */ -#define REQUEST_ENTRY_CNT 256 /* Number of request entries. */ -#define RESPONSE_ENTRY_CNT 16 /* Number of response entries. */ +#define REQUEST_ENTRY_CNT 255 /* Number of request entries. */ +#define RESPONSE_ENTRY_CNT 63 /* Number of response entries. */ /* * SCSI Request Block structure (sp) that is placed Thanks tanzy - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 19/21] advansys: Remove a couple of uses of bus_to_virt
On Tue, Oct 02, 2007 at 10:13:07PM -0400, Jeff Garzik wrote: check dma_map_single for error It's on the todo list. Since so many other drivers don't check dma_map_single for error, I feel comfortable with leaving it for later. -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] qla2xxx: add target mode support
On Mon, 01 Oct 2007 11:00:44 -0700 Seokmann Ju [EMAIL PROTECTED] wrote: FUJITA Tomonori wrote: On Thu, 27 Sep 2007 07:34:52 -0700 Seokmann Ju [EMAIL PROTECTED] wrote: FUJITA Tomonori wrote: On Fri, 21 Sep 2007 07:34:18 -0700 Seokmann Ju [EMAIL PROTECTED] wrote: Andrew Vasquez wrote: On Sat, 01 Sep 2007, FUJITA Tomonori wrote: This adds target mode support to qla2xxx. With set ql2enable_target_mode module parameter to 1, the driver runs in target mode. By default, ql2enable_target_mode is set to 0, and the driver should work in initiator mode as before. The driver could support dual-mode in the future but it doesn't at the moment (we need to add dual-mode support tgt first). It is based on scst qla2xxx target mode driver. Mike converted the driver to use tgt long ago. I changed it to use the latest (mainline) version of qla2xxx driver and tgt, and also converted it to use fc transport class. Thanks for doing this. Some initial comments before a full review is complete, As was seen from the initiator updates needed for 24xx support, there are comparable changes needed in the area of target-mode support for 4gb and 8gb parts. Also, which ISPs and firmwares were exercised with this code? The patch is still under reviewing and will get done, soon. Great, thinks! One more question on typical testing setup. I wonder how should I setup the testing environment esp., for the target-mode. Sorry, I should have explained it with the patch. Probabaly, you need to compile scsi-misc with the qla2xxx target patch and the user-space target code. 1. scsi-misc + the qla2xxx target patch CONFIG_SCSI_TGT=m CONFIG_SCSI_FC_ATTRS=m CONFIG_SCSI_FC_TGT_ATTRS=y CONFIG_SCSI_QLA_FC=m CONFIG_SCSI_QLA_FC_TGT=y 2. the user-space target code git://git.kernel.org/pub/scm/linux/kernel/git/tomo/tgt.git rouen:~/git/tgt/usr$ make FCP=1 KERNELSRC=/home/fujita/git/scsi-misc-2.6 Starting the fc target mode is not so simple now (Mike and I know that we need to fix it...). 1. load scsi_tgt.ko 2. start the user-space daemon Here's a simple example. ./tgt/usr/tgtd ./tgt/usr/tgtadm --lld fc --mode target --op new --tid 1 --targetname volume1 ./tgt/usr/tgtadm --lld fc --mode logicalunit --op new --tid 1 --lun 1 -b /var/tmp/lun1 Above command execution on the system with the HBA with target mode returns invalid request for some reason. Not sure if there are any steps that has to be in place? The configuration is as follow, - two systems + a switch + a target device (JBOD) are involved. - each of systems has a QLogic HBA in it. The HBA on one system is in initiator mode and the other one is in target mode. - each of the port of the HBAs is connected to the switch and a target device (JBOD) is connected to the switch, too. Thank you, Seokmann --- atl-01:/lib/modules/2.6.23-rc3-smp-tgt/kernel/drivers/scsi/qla2xxx # tgtadm --lld fc --mode target --op show Target 1: volume1 System information: Driver: fc Status: running I_T nexus information: LUN information: LUN: 0 Type: controller SCSI ID: deadbeaf1:0 SCSI SN: beaf10 Size: 0 Online: No Poweron/Reset: Yes Removable media: No Backing store: No backing store ACL information: You successfully created a new target but failed to add a new logical unit (#1) to it (note that lun 0 was created automatically). ./tgt/usr/tgtadm --lld fc --mode logicalunit --op new --tid 1 --lun 1 -b /var/tmp/lun1 We are try to add a regular file (/var/tmp/lun1) to the target and export it as a logical unit to initiators. Do you have /var/tmp/lun1? [EMAIL PROTECTED]:/var/tmp$ ls -l lun1 -rw-r--r-- 1 fujita fujita 67108864 2007-06-14 22:01 lun1 - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] add sg segment limitation info to device structure
On Tue, 2 Oct 2007 09:44:13 -0700
Greg KH [EMAIL PROTECTED] wrote:
On Tue, Oct 02, 2007 at 09:25:34AM -0600, Matthew Wilcox wrote:
On Tue, Oct 02, 2007 at 05:23:39PM +0200, Kay Sievers wrote:
Just looking at the number of devices, it seems that allocating it
dynamically would be the better deal. We allocate the name of every
kobject dynamically today, so I guess it's fine to do that with the
DMA data too.
But we don't need to allocate it dynamically. We can embed it in the
pci_dev, eisa_dev, zorro_dev, mca_dev and parisc_device.
But then you run into the issue that James pointed out originally.
Anyway, I don't care which, let's see some patches :)
How about this (based on James' proposal)?
- Currently, there are only max_segment_size and segment_boundary_mask
in struct device_dma_parameters (I'll add segment_boundary_mask
support later after I finish the iommu part). We'll move more dma
stuff in struct device (like dma_mask) to struct device_dma_parameters
later (needs some cleanups before that).
- New accessors for the dma parameters are added. So we can easily
change where to place struct device_dma_parameters in the future.
- the default max_segment_size is set to 64K, same to the block
layer's default value.
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 37c00f6..c93ebe8 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1392,6 +1392,13 @@ pci_set_consistent_dma_mask(struct pci_dev *dev, u64
mask)
}
#endif
+#ifndef HAVE_ARCH_PCI_SET_DMA_MAX_SEGMENT_SIZE
+int pci_set_dma_max_seg_size(struct pci_dev *dev, unsigned int size)
+{
+ return dma_set_max_seg_size(dev-dev, size);
+}
+#endif
+
/**
* pcix_get_max_mmrbc - get PCI-X maximum designed memory read byte count
* @dev: PCI device to query
@@ -1624,6 +1631,7 @@ EXPORT_SYMBOL(pci_clear_mwi);
EXPORT_SYMBOL_GPL(pci_intx);
EXPORT_SYMBOL(pci_set_dma_mask);
EXPORT_SYMBOL(pci_set_consistent_dma_mask);
+EXPORT_SYMBOL(pci_set_dma_max_seg_size);
EXPORT_SYMBOL(pci_assign_resource);
EXPORT_SYMBOL(pci_find_parent_resource);
EXPORT_SYMBOL(pci_select_bars);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 171ca71..2a18134 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -948,8 +948,11 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus
*bus)
set_dev_node(dev-dev, pcibus_to_node(bus));
dev-dev.dma_mask = dev-dma_mask;
+ dev-dev.dma_parms = dev-dma_parms;
dev-dev.coherent_dma_mask = 0xull;
+ pci_set_dma_max_seg_size(dev, 65536);
+
/* Fix up broken headers */
pci_fixup_device(pci_fixup_header, dev);
diff --git a/include/linux/device.h b/include/linux/device.h
index 3a38d1f..3c24932 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -404,6 +404,15 @@ extern int devres_release_group(struct device *dev, void
*id);
extern void *devm_kzalloc(struct device *dev, size_t size, gfp_t gfp);
extern void devm_kfree(struct device *dev, void *p);
+struct device_dma_parameters {
+ /*
+* a low level driver may set these to teach IOMMU code about
+* sg limitations.
+*/
+ unsigned int max_segment_size;
+ unsigned long segment_boundary_mask;
+};
+
struct device {
struct klistklist_children;
struct klist_node knode_parent; /* node in sibling list
*/
@@ -439,6 +448,8 @@ struct device {
64 bit addresses for consistent
allocations such descriptors. */
+ struct device_dma_parameters *dma_parms;
+
struct list_headdma_pools; /* dma pools (if dma'ble) */
struct dma_coherent_mem *dma_mem; /* internal for coherent mem
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 2dc21cb..02854c8 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -43,6 +43,21 @@ static inline int valid_dma_direction(int dma_direction)
extern u64 dma_get_required_mask(struct device *dev);
+static inline unsigned int dma_get_max_seg_size(struct device *dev)
+{
+ return dev-dma_parms ? dev-dma_parms-max_segment_size : 65536;
+}
+
+static inline unsigned int dma_set_max_seg_size(struct device *dev,
+ unsigned int size)
+{
+ if (dev-dma_parms) {
+ dev-dma_parms-max_segment_size = size;
+ return 0;
+ } else
+ return -EIO;
+}
+
/* flags for the coherent memory api */
#defineDMA_MEMORY_MAP 0x01
#define DMA_MEMORY_IO 0x02
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 038a0dc..1d630b5 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -151,6 +151,8 @@ struct pci_dev {
this if your device has broken DMA
or supports
Re: [PATCH 19/21] advansys: Remove a couple of uses of bus_to_virt
Matthew Wilcox wrote: On Tue, Oct 02, 2007 at 10:13:07PM -0400, Jeff Garzik wrote: check dma_map_single for error It's on the todo list. Since so many other drivers don't check dma_map_single for error, I feel comfortable with leaving it for later. The issue became more urgent with x86-64 and its smaller IOMMU area. Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 19/21] advansys: Remove a couple of uses of bus_to_virt
On Wed, Oct 03, 2007 at 10:28:31AM -0400, Jeff Garzik wrote: Matthew Wilcox wrote: On Tue, Oct 02, 2007 at 10:13:07PM -0400, Jeff Garzik wrote: check dma_map_single for error It's on the todo list. Since so many other drivers don't check dma_map_single for error, I feel comfortable with leaving it for later. The issue became more urgent with x86-64 and its smaller IOMMU area. I'll bump up the priority of fixing it then. I don't think this should block the series from going in (since it wasn't even compilable on x86-64 before this point). -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 21/21] advansys: Changes to work on parisc
Christoph Hellwig wrote: On Tue, Oct 02, 2007 at 10:28:29PM -0400, Jeff Garzik wrote: Incorrect. That is highly platform specific, with many using unsigned long, since the [non-x86] platform is generally pointing to a special memory region rather than directly using an x86-like instruction. For port I/O we _do_ use int everywhere. ioport_map() disagrees with you. request_region disagrees with you. release_region disagrees with you. ia64 disagrees with you. alpha disagrees with you. sparc64 disagrees with you. sh disagrees with you. serial driver disagrees with you. pcmcia disagrees with you. net driver history disagrees with you. It should also be self-evident from READING THE ARCH CODE that a 64-bit arch is allowed to fill in a 64-bit address in an IORESOURCE_IO struct resource. Thus, unsigned long is the least common demoninator. unsigned long is the ONLY way to guarantee portability. Not all port I/O is hardcoded legacy ISA addresses. Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 19/21] advansys: Remove a couple of uses of bus_to_virt
Matthew Wilcox wrote: On Wed, Oct 03, 2007 at 10:28:31AM -0400, Jeff Garzik wrote: Matthew Wilcox wrote: On Tue, Oct 02, 2007 at 10:13:07PM -0400, Jeff Garzik wrote: check dma_map_single for error It's on the todo list. Since so many other drivers don't check dma_map_single for error, I feel comfortable with leaving it for later. The issue became more urgent with x86-64 and its smaller IOMMU area. I'll bump up the priority of fixing it then. I don't think this should block the series from going in (since it wasn't even compilable on x86-64 before this point). Oh, certainly agreed... I never used the word NAK. Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: generating a Linux WWN?
Jeff Garzik wrote: Luben Tuikov wrote: --- Jeff Garzik [EMAIL PROTECTED] wrote: The admin will have the option to auto-generate a WWN, should they so desire. What does that mean? auto-generate? By whom? The admin tells the kernel module to auto-generate a WWN, and the kernel module happily obliges. The generation algorithm is whatever makes people happy. I would probably pick a fixed prefix like 0x6C 0x69 0x63 (lin), something that doesn't conflict with IEEE org ids for a long time to come. Then, get_random_bytes() or hash some useful machine characteristics for the rest of the bytes. What if they don't auto-generate (whatever that means)? Well, you either have a WWN or you don't :) Jeff, It is not quite black and white. As I tried to point out, when a SAS HBA is run in target mode, there is a good chance there aren't _enough_ unique SAS addresses allocated by the manufacturer. There should be naa-5 addresses for the ports, it is the target device address and 0 or more lu addresses that may need to be generated. Doug Gilbert - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: generating a Linux WWN?
Jeff Garzik wrote: Luben Tuikov wrote: Do you mean: The admin will have the option to SPECIFY(SET) a WWN, should they sodesire. OR do you mean: The admin will have the option to HAVE THE KERNEL auto-generate a WWN, should they so desire. Both. It is up to admin policy to decide if they wish to use the available board's WWN (if present/valid), manually apportion WWNs, or whether the kernel's generation algo is fine with them. Could the reassignment of a board's WWN present any security issues? A board which is allowed to access only some targets is now allowed to access others. I would assume that most sites that care about security would have other measures in place to guard against this, but it's still worth pondering. Mike Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/16] gdth: split out eisa probing
Boaz Harrosh wrote:
Split eisa probing into it's own helper, and do proper error unwinding.
Protect EISA probind by the proper CONFIG_EISA symbol.
Signed-off-by: Christoph Hellwig [EMAIL PROTECTED]
@@ -5694,6 +5582,148 @@ static int gdth_isa_probe_one(struct
scsi_host_template *shtp, ulong32 isa_bios) }
#endif /* CONFIG_ISA */
+#ifdef CONFIG_EISA
+static int gdth_eisa_probe_one(struct scsi_host_template *shtp,
+ ushort eisa_slot)
+{
+ struct Scsi_Host *shp;
+ gdth_ha_str *ha;
+ dma_addr_t scratch_dma_handle = 0;
+ int error, hanum, i;
+ u8 b;
+
+ if (!gdth_search_eisa(eisa_slot))
+ return -ENXIO;
+
+ shp = scsi_register(shtp,sizeof(gdth_ext_str));
+ if (!shp)
+ return -ENOMEM;
+ ha = HADATA(shp);
+
+ error = -ENODEV;
+ if (!gdth_init_eisa(eisa_slot,ha))
+ goto out_host_put;
+
+ /* controller found and initialized */
+ printk(Configuring GDT-EISA HA at Slot %d IRQ %u\n,
+ eisa_slot 12, ha-irq);
+
+ error = request_irq(ha-irq, gdth_interrupt, IRQF_DISABLED, gdth, ha);
+ if (error) {
+ printk(GDT-EISA: Unable to allocate IRQ\n);
+ goto out_host_put;
+ }
+
+ shp-unchecked_isa_dma = 0;
+ shp-irq = ha-irq;
+ shp-dma_channel = 0xff;
+ hanum = gdth_ctr_count;
+ gdth_ctr_tab[gdth_ctr_count++] = shp;
+ gdth_ctr_vtab[gdth_ctr_vcount++] = shp;
+
+ NUMDATA(shp)-hanum = (ushort)hanum;
+ NUMDATA(shp)-busnum= 0;
+ TRACE2((EISA detect Bus 0: hanum %d\n,
+ NUMDATA(shp)-hanum));
+
+ ha-pccb = CMDDATA(shp);
+ ha-ccb_phys = 0L;
+
+ error = -ENOMEM;
+
+ ha-pdev = NULL;
+ ha-pscratch = pci_alloc_consistent(ha-pdev, GDTH_SCRATCH,
+ scratch_dma_handle);
+ if (!ha-pscratch)
+ goto out_free_irq;
+ ha-scratch_phys = scratch_dma_handle;
+
+ ha-pmsg = pci_alloc_consistent(ha-pdev, sizeof(gdth_msg_str),
+ scratch_dma_handle);
+ if (!ha-pmsg)
+ goto out_free_pscratch;
+ ha-msg_phys = scratch_dma_handle;
+
+#ifdef INT_COAL
+ ha-coal_stat = pci_alloc_consistent(ha-pdev,
+ sizeof(gdth_coal_status) * MAXOFFSETS,
+ scratch_dma_handle);
+ if (!ha-coal_stat)
+ goto out_free_pmsg;
+ ha-coal_stat_phys = scratch_dma_handle;
+#endif
+
+ ha-ccb_phys = pci_map_single(ha-pdev,ha-pccb,
+ sizeof(gdth_cmd_str), PCI_DMA_BIDIRECTIONAL);
+ if (!ha-ccb_phys)
+ goto out_free_coal_stat;
Same thing as in ISA patch: this is not PCI and we should not hide what we're
doing so dma_alloc_consistent(NULL, ...) is better IMHO.
Eike
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH 1/16] gdth: split out isa probing
Boaz Harrosh wrote:
(note: this is ontop of Jeff's pci cleanup patch)
Split out isa probing into a helper of it's own. Error handling is
cleaned up, but errors are not propagated yet. Also enclose the isa
probe under the proper CONFIG_ISA symbol instead of the !IA64 hack.
Signed-off-by: Christoph Hellwig [EMAIL PROTECTED]
@@ -4277,6 +4280,7 @@ int __init option_setup(char *str)
return 1;
}
+
#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,0)
static int __init gdth_detect(struct scsi_host_template *shtp)
#else
Extra newline for nothing?
@@ -5668,6 +5552,149 @@ static Scsi_Host_Template driver_template = {
#endif
};
+#ifdef CONFIG_ISA
+static int gdth_isa_probe_one(struct scsi_host_template *shtp, ulong32
isa_bios) +{
+ struct Scsi_Host *shp;
+ gdth_ha_str *ha;
+ dma_addr_t scratch_dma_handle = 0;
+ int error, hanum, i;
+ u8 b;
+
+ if (!gdth_search_isa(isa_bios))
+ return -ENXIO;
+
+ shp = scsi_register(shtp, sizeof(gdth_ext_str));
+ if (!shp)
+ return -ENOMEM;
+ ha = HADATA(shp);
+
+ error = -ENODEV;
+ if (!gdth_init_isa(isa_bios,ha))
+ goto out_host_put;
+
+ /* controller found and initialized */
+ printk(Configuring GDT-ISA HA at BIOS 0x%05X IRQ %u DRQ %u\n,
+ isa_bios, ha-irq, ha-drq);
+
+ error = request_irq(ha-irq, gdth_interrupt, IRQF_DISABLED, gdth, ha);
+ if (error) {
+ printk(GDT-ISA: Unable to allocate IRQ\n);
+ goto out_host_put;
+ }
+
+ error = request_dma(ha-drq, gdth);
+ if (error) {
+ printk(GDT-ISA: Unable to allocate DMA channel\n);
+ goto out_free_irq;
+ }
+
+ set_dma_mode(ha-drq,DMA_MODE_CASCADE);
+ enable_dma(ha-drq);
+ shp-unchecked_isa_dma = 1;
+ shp-irq = ha-irq;
+ shp-dma_channel = ha-drq;
+ hanum = gdth_ctr_count;
+ gdth_ctr_tab[gdth_ctr_count++] = shp;
+ gdth_ctr_vtab[gdth_ctr_vcount++] = shp;
+
+ NUMDATA(shp)-hanum = (ushort)hanum;
+ NUMDATA(shp)-busnum= 0;
+
+ ha-pccb = CMDDATA(shp);
+ ha-ccb_phys = 0L;
+ ha-pdev = NULL;
+
+ error = -ENOMEM;
+
+ ha-pscratch = pci_alloc_consistent(ha-pdev, GDTH_SCRATCH,
+ scratch_dma_handle);
+ if (!ha-pscratch)
+ goto out_dec_counters;
+ ha-scratch_phys = scratch_dma_handle;
+
+ ha-pmsg = pci_alloc_consistent(ha-pdev, sizeof(gdth_msg_str),
+ scratch_dma_handle);
+ if (!ha-pmsg)
+ goto out_free_pscratch;
+ ha-msg_phys = scratch_dma_handle;
+
+#ifdef INT_COAL
+ ha-coal_stat = pci_alloc_consistent(ha-pdev,
+ sizeof(gdth_coal_status) * MAXOFFSETS,
+ scratch_dma_handle);
+ if (!ha-coal_stat)
+ goto out_free_pmsg;
+ ha-coal_stat_phys = scratch_dma_handle;
+#endif
What we have here is cleanly not PCI memory as it's ISA initialisation. And
for making things obvious passing NULL as first argument of
dma_alloc_consistent() is IMHO the better way.
Greetings,
Eike
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH 15/16] gdth: Move members from SCp to gdth_cmndinfo, stage 2
Boaz Harrosh wrote:
- Cleanup the rest of the scsi_cmnd-SCp members and move them
to gdth_cmndinfo:
SCp.have_data_in = volatile wait_for_completion
Signed-off-by Boaz Harrosh [EMAIL PROTECTED]
volatile here is probably nonsense. Either you need proper locking on this
struct in case there may be side-effects between different callers or it's
unneeded at all. This looks really suspicious:
--- a/drivers/scsi/gdth_proc.c
+++ b/drivers/scsi/gdth_proc.c
@@ -728,20 +728,22 @@ static void gdth_wait_completion(gdth_ha_str *ha, int
busnum, int id)
ulong flags;
int i;
Scsi_Cmnd *scp;
+struct gdth_cmndinfo *cmndinfo;
unchar b, t;
spin_lock_irqsave(ha-smp_lock, flags);
for (i = 0; i GDTH_MAXCMDS; ++i) {
scp = ha-cmd_tab[i].cmnd;
+cmndinfo = gdth_cmnd_priv(scp);
b = scp-device-channel;
t = scp-device-id;
if (!SPECIAL_SCP(scp) t == (unchar)id
b == (unchar)busnum) {
-scp-SCp.have_data_in = 0;
+cmndinfo-wait_for_completion = 0;
spin_unlock_irqrestore(ha-smp_lock, flags);
-while (!scp-SCp.have_data_in)
+while (!cmndinfo-wait_for_completion)
barrier();
I haven't checked for locking around the other accesses, but they look racy.
This looks like wasting CPU cycles by busy-looping for a change. And for
things like these
@@ -3511,8 +3514,8 @@ static int gdth_sync_event(gdth_ha_str *ha, int service,
unchar index,
}
}
}
-if (!scp-SCp.have_data_in)
-scp-SCp.have_data_in++;
+if (!cmndinfo-wait_for_completion)
+cmndinfo-wait_for_completion++;
probably atomic_inc_not_zero() should be used if it is really needed at all.
Greetings,
Eike
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH 1/16] gdth: split out isa probing
Rolf Eike Beer wrote: What we have here is cleanly not PCI memory as it's ISA initialisation. And for making things obvious passing NULL as first argument of dma_alloc_consistent() is IMHO the better way. While this is true, this is largely a code movement patch. It's up to Boaz/Christoph whether they want to include another cleanup in this patch, or move that to separate patch that switches the driver to dma_xxx Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: generating a Linux WWN?
Michael Reed wrote: Jeff Garzik wrote: Luben Tuikov wrote: Do you mean: The admin will have the option to SPECIFY(SET) a WWN, should they sodesire. OR do you mean: The admin will have the option to HAVE THE KERNEL auto-generate a WWN, should they so desire. Both. It is up to admin policy to decide if they wish to use the available board's WWN (if present/valid), manually apportion WWNs, or whether the kernel's generation algo is fine with them. Could the reassignment of a board's WWN present any security issues? A board which is allowed to access only some targets is now allowed to access others. I would assume that most sites that care about security would have other measures in place to guard against this, but it's still worth pondering. Well, at that point the admin has made a conscious decision to deviate from the norm, either for site-specific reasons or for getting-his-hardware-working reasons. So we assume the admin who made a proactive step in this direction knows what he is doing. Just like the rest of Linux, we just give you the rope... :) Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: generating a Linux WWN?
Douglas Gilbert wrote: Jeff Garzik wrote: Luben Tuikov wrote: --- Jeff Garzik [EMAIL PROTECTED] wrote: The admin will have the option to auto-generate a WWN, should they so desire. What does that mean? auto-generate? By whom? The admin tells the kernel module to auto-generate a WWN, and the kernel module happily obliges. The generation algorithm is whatever makes people happy. I would probably pick a fixed prefix like 0x6C 0x69 0x63 (lin), something that doesn't conflict with IEEE org ids for a long time to come. Then, get_random_bytes() or hash some useful machine characteristics for the rest of the bytes. What if they don't auto-generate (whatever that means)? Well, you either have a WWN or you don't :) Jeff, It is not quite black and white. As I tried to point out, when a SAS HBA is run in target mode, there is a good chance there aren't _enough_ unique SAS addresses allocated by the manufacturer. There should be naa-5 addresses for the ports, it is the target device address and 0 or more lu addresses that may need to be generated. Oh quite agreed ... I was definitely talking about the initiator. The thread has come full circle again :) I would definitely like to figure out a standard way to generate new SAS addresses. Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH ver4 1/5] scsi_error: code cleanup before refactoring of scsi_send_eh_cmnd()
On Tue, 2007-09-11 at 20:39 +0300, Boaz Harrosh wrote:
- regrouped variables for easier reviewing of next patch
- Support of cmnd==NULL in call to scsi_send_eh_cmnd()
- In the copy_sense case set transfer size to the minimum
size of sense_buffer and passed @sense_bytes. cmnd[4] is
set accordingly.
- REQUEST_SENSE is set into cmnd[0] so if @sense_bytes is
not Zero passed cmnd can/should be NULL.
- Also save/restore resid of faild command.
Signed-off-by: Boaz Harrosh [EMAIL PROTECTED]
---
drivers/scsi/scsi_error.c | 69
1 files changed, 38 insertions(+), 31 deletions(-)
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index c8e351f..11c928d 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -607,21 +607,24 @@ static void scsi_abort_eh_cmnd(struct scsi_cmnd *scmd)
*SUCCESS or FAILED or NEEDS_RETRY
**/
static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd, unsigned char *cmnd,
- int cmnd_size, int timeout, int copy_sense)
+ int cmnd_size, int timeout, unsigned sense_bytes)
You've altered the signature and function of the routine here, this
needs to be documented by updating the docbook description above the
function. (I know you do it later, but each changeset should really be
logically complete).
{
struct scsi_device *sdev = scmd-device;
struct Scsi_Host *shost = sdev-host;
- int old_result = scmd-result;
DECLARE_COMPLETION_ONSTACK(done);
unsigned long timeleft;
unsigned long flags;
- struct scatterlist sgl;
+
+ unsigned char old_cmd_len;
unsigned char old_cmnd[MAX_COMMAND_SIZE];
enum dma_data_direction old_data_direction;
- unsigned short old_use_sg;
- unsigned char old_cmd_len;
unsigned old_bufflen;
void *old_buffer;
+ unsigned short old_use_sg;
+ int old_resid;
+ int old_result;
+
+ struct scatterlist sgl;
int rtn;
/*
@@ -631,24 +634,37 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd,
unsigned char *cmnd,
* we will need to restore these values prior to running the actual
* command.
*/
- old_buffer = scmd-request_buffer;
- old_bufflen = scmd-request_bufflen;
+ old_cmd_len = scmd-cmd_len;
memcpy(old_cmnd, scmd-cmnd, sizeof(scmd-cmnd));
old_data_direction = scmd-sc_data_direction;
- old_cmd_len = scmd-cmd_len;
+ old_bufflen = scmd-request_bufflen;
+ old_buffer = scmd-request_buffer;
old_use_sg = scmd-use_sg;
+ old_resid = scmd-resid;
+ old_result = scmd-result;
- memset(scmd-cmnd, 0, sizeof(scmd-cmnd));
- memcpy(scmd-cmnd, cmnd, cmnd_size);
-
- if (copy_sense) {
- sg_init_one(sgl, scmd-sense_buffer,
- sizeof(scmd-sense_buffer));
+ if (cmnd) {
+ memset(scmd-cmnd, 0, sizeof(scmd-cmnd));
+ memcpy(scmd-cmnd, cmnd, cmnd_size);
+ scmd-cmd_len = COMMAND_SIZE(scmd-cmnd[0]);
+ }
- scmd-sc_data_direction = DMA_FROM_DEVICE;
- scmd-request_bufflen = sgl.length;
+ if (sense_bytes) {
+ scmd-request_bufflen = min_t(unsigned,
+sizeof(scmd-sense_buffer), sense_bytes);
+ sg_init_one(sgl, scmd-sense_buffer, scmd-request_bufflen);
scmd-request_buffer = sgl;
+ scmd-sc_data_direction = DMA_FROM_DEVICE;
scmd-use_sg = 1;
+ memset(scmd-cmnd, 0, 6);
This will lead to subtle bugs: some devices (notably ATAPI) have a fixed
command slot they will copy this into. You have potentially trailing
bytes of junk that this could pick up ... we have ATAPI devices known to
fall over if they see trailing junk in the command. Just consolidate
the scmd-cmnd memsets to
memset(scmd-cmnd, 0, sizeof(scmd-cmnd);
outside of the ifs
+ scmd-cmnd[0] = REQUEST_SENSE;
+ scmd-cmnd[4] = scmd-request_bufflen;
+ scmd-cmd_len = COMMAND_SIZE(scmd-cmnd[0]);
+ /*
+ * Zero the sense buffer. The scsi spec mandates that any
+ * untransferred sense data should be interpreted as being zero.
+ */
+ memset(scmd-sense_buffer, 0, sizeof(scmd-sense_buffer));
} else {
scmd-request_buffer = NULL;
scmd-request_bufflen = 0;
@@ -657,18 +673,11 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd,
unsigned char *cmnd,
}
scmd-underflow = 0;
- scmd-cmd_len = COMMAND_SIZE(scmd-cmnd[0]);
- if (sdev-scsi_level = SCSI_2)
+ if (sdev-scsi_level = SCSI_2 sdev-scsi_level != SCSI_UNKNOWN)
scmd-cmnd[1] = (scmd-cmnd[1] 0x1f) |
(sdev-lun 5 0xe0);
- /*
- * Zero the sense buffer. The scsi
Re: [PATCH ver3 2/5] scsi_error: Refactoring scsi_error to facilitate in synchronous REQUEST_SENSE
On Tue, 2007-09-11 at 11:04 +0300, Boaz Harrosh wrote: - Drivers/transports that want to send a synchronous REQUEST_SENSE command as part of their .queuecommand sequence, have 2 new API's that facilitate in doing so and abstract them from scsi-ml internals. void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd, struct scsi_eh_save *sesci, unsigned char *cmnd, int cmnd_size, int sense_bytes) Will hijack a command and prepare it for request sense if needed. And will save any later needed info into a scsi_eh_save structure. void scsi_eh_restore_cmnd(struct scsi_cmnd* scmd, struct scsi_eh_save *sesci); Will undo any changes done to a command by above function. Making it ready for completion. - Re-factor scsi_send_eh_cmnd() to use above APIs Signed-off-by: Boaz Harrosh [EMAIL PROTECTED] This one looks OK, but it will likely not apply when you fix the first patch, so could you rebase and resend this as well. Thanks, James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/16] gdth: split out eisa probing
On Wed, Oct 03, 2007 at 07:32:24PM +0200, Rolf Eike Beer wrote: It's not about passing NULL there. We need to do that. But we should call it with NULL as argument and not with ha-pdev to make this obvious. Feel free to send your cleanup patches once we've finished doing the important heavy lifting on gdth. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/16] gdth: split out eisa probing
On Tue, Oct 02, 2007 at 07:20:38PM +0200, Rolf Eike Beer wrote: Same thing as in ISA patch: this is not PCI and we should not hide what we're doing so dma_alloc_consistent(NULL, ...) is better IMHO. passing NULL is the documented way to deal with ISA/EISA devices with the old pci dma api. Any change to these APIs should be a different patch, and there's about 100 more important things in gdth right now. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] add sg segment limitation info to device structure
FUJITA Tomonori wrote: On Tue, 2 Oct 2007 09:44:13 -0700 Greg KH [EMAIL PROTECTED] wrote: On Tue, Oct 02, 2007 at 09:25:34AM -0600, Matthew Wilcox wrote: On Tue, Oct 02, 2007 at 05:23:39PM +0200, Kay Sievers wrote: Just looking at the number of devices, it seems that allocating it dynamically would be the better deal. We allocate the name of every kobject dynamically today, so I guess it's fine to do that with the DMA data too. But we don't need to allocate it dynamically. We can embed it in the pci_dev, eisa_dev, zorro_dev, mca_dev and parisc_device. But then you run into the issue that James pointed out originally. Anyway, I don't care which, let's see some patches :) How about this (based on James' proposal)? - Currently, there are only max_segment_size and segment_boundary_mask in struct device_dma_parameters (I'll add segment_boundary_mask support later after I finish the iommu part). We'll move more dma stuff in struct device (like dma_mask) to struct device_dma_parameters later (needs some cleanups before that). - New accessors for the dma parameters are added. So we can easily change where to place struct device_dma_parameters in the future. - the default max_segment_size is set to 64K, same to the block layer's default value. ACK - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/16] gdth: split out eisa probing
Christoph Hellwig wrote: On Wed, Oct 03, 2007 at 07:32:24PM +0200, Rolf Eike Beer wrote: It's not about passing NULL there. We need to do that. But we should call it with NULL as argument and not with ha-pdev to make this obvious. Feel free to send your cleanup patches once we've finished doing the important heavy lifting on gdth. Come on. The patches were posted for comments, and Rolf commented. Don't give him a hard time for a valid comment. Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: generating a Linux WWN?
The generation algorithm is whatever makes people happy. I would probably pick a fixed prefix like 0x6C 0x69 0x63 (lin), something that doesn't conflict with IEEE org ids for a long time to come. Then, get_random_bytes() or hash some useful machine characteristics for the rest of the bytes. The probably here is kind of amusing. Look, Linux development has the moolah (look at all the money IBM and SGI and others have shoveled in)- why don't you get a Linux block of OUIs from the IEEE and set up an RSS-like feed so the Open Source community can get WWNs with that OUI and a incrementing serial number as needed- that would be a *real* service. I've thought about doing this, but I'd have to fork over at least 1700$USD to get an official IEEE OUI and over the last ten years I've already spent far too much of my own money on open source support. Heck, maybe even the IEEE would comp you on OUIs. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/16] gdth: split out eisa probing
On Wed, Oct 03, 2007 at 01:59:23PM -0400, Jeff Garzik wrote: Come on. The patches were posted for comments, and Rolf commented. Don't give him a hard time for a valid comment. Sorry, but these comments are utterly useless. It's not like we're doing anything related to dma mapping, but just moving some init code around. If we actually did a major change in how dma mapping is handled the comment would be apropinquate and a switchover should happen as part of the patch series. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/16] gdth: split out eisa probing
Christoph Hellwig wrote: On Wed, Oct 03, 2007 at 01:59:23PM -0400, Jeff Garzik wrote: Come on. The patches were posted for comments, and Rolf commented. Don't give him a hard time for a valid comment. Sorry, but these comments are utterly useless. It's not like we're doing anything related to dma mapping, but just moving some init code around. If we actually did a major change in how dma mapping is handled the comment would be apropinquate and a switchover should happen as part of the patch series. A comment noting a useful improvement is always helpful, even if it cannot be addressed immediately. Please don't push reviewers away. That severely demotivates other reviewers, when they see such treatment. We talked about this at the Kernel Summit. Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: generating a Linux WWN?
Matthew Jacob wrote: The generation algorithm is whatever makes people happy. I would probably pick a fixed prefix like 0x6C 0x69 0x63 (lin), something that doesn't conflict with IEEE org ids for a long time to come. Then, get_random_bytes() or hash some useful machine characteristics for the rest of the bytes. The probably here is kind of amusing. Look, Linux development has the moolah (look at all the money IBM and SGI and others have shoveled in)- why don't you get a Linux block of OUIs from the IEEE and set up an RSS-like feed so the Open Source community can get WWNs with that OUI and a incrementing serial number as needed- that would be a *real* service. I've thought about doing this, but I'd have to fork over at least 1700$USD to get an official IEEE OUI and over the last ten years I've already spent far too much of my own money on open source support. Heck, maybe even the IEEE would comp you on OUIs. Certainly, I would love for this to happen! Although my employer (Red Hat), SGI, IBM or whomever might be willing to tackle this, it might be more appropriate for the Linux Foundation. Anybody wanna volunteer to pursue this? Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/16] gdth: Move members from SCp to gdth_cmndinfo, stage 2
On Tue, Oct 02, 2007 at 08:02:45PM +0200, Rolf Eike Beer wrote: volatile here is probably nonsense. Either you need proper locking on this struct in case there may be side-effects between different callers or it's unneeded at all. This looks really suspicious: Yes, it's most likely wrong. But for now there's a really huge plate of patches already, and we'd rather keep behaviour similar. Once we've managed to actually test this big pile we can move on to cleaning up things like that. And I suspect part of the right solution will be to get rid of this busy loop entirely. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 16/17] mptbase: reset ioc initiator during PCI resume
On Tuesday, October 02, 2007 5:06 PM, Darrick J. Wong wrote: Yep. Replied to it, too. Apparently it never got to you, so I've attached it below. Sorry, I didn't receive the previous email you sent. - On Thu, Sep 20, 2007 at 07:06:35PM -0600, Moore, Eric wrote: Darrick - MESSAGE_UNIT_RESET is already issued from inside mpt_do_ioc_recovery(), so you don't need to send this in advance of that.YOu will find that occuring from the function MakeIocReady. Anyways... would it be possible for you to enable debug logging so I can see what problem your having? I suggest MPT_DEBUG and MPT_DEBUG_INIT. If its possible for you to manually load mptbase, that way you can set the command line option. I took a look at MakeIocReady(), and this section caught my eye: /* Is it already READY? */ if (!statefault (ioc_state MPI_IOC_STATE_MASK) == MPI_IOC_STATE_READY) return 0; Yes, the purpose of MakeIocReady is to get the card in READY state. If your already in READY state, there is no reason to continue in MakeIocReady. A MESSAGE_UNIT_RESET places the card into READY state. You will see that we already issued MESSAGE_UNIT_RESET from mptbase_suspend. So it should be in READY state coming into mptbase_resume, depending on which power state you transferred to from suspend.The code you added in this patch is not required, meaning we dont need to send MESSAGE_UNIT_RESET prior to ioc_do_recovery, becuase from MakeIocReady will issue a MESSAGE_UNIT_RESET if your not already in READY.I suspect there must be something else going on if you have to issue MESSAGE_UNIT_RESET when your already in READY state. My card works fine without your patch. I did the following: # echo standby /sys/power/state There could be issues in the firmware your using. I noticed FwRev=00060200h in the log,, which is 6.02, and over a year old. I will send out a seperate email which I will copy you to the IBM system engineer support here at LSI, should be able to assist on this issue. Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: generating a Linux WWN?
--- Jeff Garzik [EMAIL PROTECTED] wrote: Matthew Jacob wrote: The generation algorithm is whatever makes people happy. I would probably pick a fixed prefix like 0x6C 0x69 0x63 (lin), something that doesn't conflict with IEEE org ids for a long time to come. Then, get_random_bytes() or hash some useful machine characteristics for the rest of the bytes. The probably here is kind of amusing. Look, Linux development has the moolah (look at all the money IBM and SGI and others have shoveled in)- why don't you get a Linux block of OUIs from the IEEE and set up an RSS-like feed so the Open Source community can get WWNs with that OUI and a incrementing serial number as needed- that would be a *real* service. I've thought about doing this, but I'd have to fork over at least 1700$USD to get an official IEEE OUI and over the last ten years I've already spent far too much of my own money on open source support. Heck, maybe even the IEEE would comp you on OUIs. Certainly, I would love for this to happen! Although my employer (Red Hat), SGI, IBM or whomever might be willing to tackle this, it might be more appropriate for the Linux Foundation. Anybody wanna volunteer to pursue this? SAS WWN have nothing to do with Linux. The kernel should not generate SAS WWN and assign them to SAS initiator ports. SAS WWNs should be given to SAS initiator ports and SAS target ports by a storage management application which maintains and configures the storage domain, zoning, permissions, connectivity, etc. What is needed is persistence, regardless of reboots of what OS is running on the host CPU/system. SAS WWNs are properties of the SAS target/initiator port, they are not properties of when the host system was booted, or what OS is running on it. Think about it this way: you don't change your name every morning you wake up and MAC addresses are not generated by the kernel for a network device which has none. Those are persistent across reboots or type of host OS. Luben - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] qla2xxx: add target mode support
FUJITA Tomonori wrote: On Mon, 01 Oct 2007 11:00:44 -0700 Seokmann Ju [EMAIL PROTECTED] wrote: atl-01:/lib/modules/2.6.23-rc3-smp-tgt/kernel/drivers/scsi/qla2xxx # tgtadm --lld fc --mode target --op show Target 1: volume1 System information: Driver: fc Status: running I_T nexus information: LUN information: LUN: 0 Type: controller SCSI ID: deadbeaf1:0 SCSI SN: beaf10 Size: 0 Online: No Poweron/Reset: Yes Removable media: No Backing store: No backing store ACL information: You successfully created a new target but failed to add a new logical unit (#1) to it (note that lun 0 was created automatically). Yes, I have noticed it. ./tgt/usr/tgtadm --lld fc --mode logicalunit --op new --tid 1 --lun 1 -b /var/tmp/lun1 We are try to add a regular file (/var/tmp/lun1) to the target and export it as a logical unit to initiators. Do you have /var/tmp/lun1? With the creation of an empty file, it started to display the lun1. --- atl-01:~ # tgtadm --lld fc --mode target --op show Target 1: tgt-vol1 System information: Driver: fc Status: running I_T nexus information: I_T nexus: f6fb6000 LUN information: LUN: 0 Type: controller SCSI ID: deadbeaf1:0 SCSI SN: beaf10 Size: 0 Online: No Poweron/Reset: Yes Removable media: No Backing store: No backing store LUN: 1 Type: disk SCSI ID: deadbeaf1:1 SCSI SN: beaf11 Size: 0 Online: Yes Poweron/Reset: Yes Removable media: No Backing store: /var/tmp/lun1 ACL information: atl-01:~ # --- However, from the initiator, still not be able to see the target - from the lsscsi, no other devices (controller/virtual-disk) than those physical devices available on the fabric. Instead, the host with target-mode displays following messages, --- Oct 3 11:21:13 atl-01 kernel: q2t_it_nexus_response 1191: dff46400 0 Oct 3 11:21:13 atl-01 kernel: q2t_it_nexus_response 1191: dff46400 0 --- If I understood correctly, the F/W on the host with target-mode should have gotten some SCSI commands from the host with initiator-mode by now. And those commands should have been forwarded to the target driver via the interrupt handler (qla24xx_intr_handler()). Just for my learning, could you share with me which of the F/W version (on the target-mode QLogic FC HBA) you are using? Thank you, Seokmann [EMAIL PROTECTED]:/var/tmp$ ls -l lun1 -rw-r--r-- 1 fujita fujita 67108864 2007-06-14 22:01 lun1 - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git-misc-all updated
Just updated jgarzik/misc-2.6.git#ALL... 'ALL' meta-branch contains these branches, exported for review and testing: dmi-const DMI subsystem constification -- added your fix/warning patches isdn-cleanups ISDN subsystem cleanups for 2.6.24 -- no word from Karsten after repeated pings -- added another couple code movement patches (moved from branch isdn-pci to this one) pciseg x86/x86-64 PCI domain support sas new drivers broadsas, mvsas -- new branch; this is my devel tree for these drivers Regards, Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH [2/8] scsi: megaraid_sas - add module param fast_load
Driver will skip physical devices scan for the first time if the fast_load is
set. This is to reduce time for loading driver.
Signed-off-by: Bo Yang [EMAIL PROTECTED]
---
drivers/scsi/megaraid/megaraid_sas.c | 69 +++--
1 files changed, 55 insertions(+), 14 deletions(-)
diff -uprN linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c
linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.c
--- linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c 2007-10-01
00:03:59.0 -0700
+++ linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.c 2007-10-01
00:12:54.0 -0700
@@ -46,6 +46,22 @@
#include scsi/scsi_host.h
#include megaraid_sas.h
+/*
+ * Module parameters
+ */
+
+/*
+ * Fast driver load option, skip scanning for physical devices during
+ * load. This would result in physical devices being skipped during
+ * driver load time. These can be later added though,
+ * using /proc/scsi/scsi
+ */
+static unsigned int fast_load;
+module_param_named(fast_load, fast_load, int, 0);
+MODULE_PARM_DESC(fast_load,
+ megasas: Faster loading of the driver, skips physical devices! \
+ (default = 0));
+
MODULE_LICENSE(GPL);
MODULE_VERSION(MEGASAS_VERSION);
MODULE_AUTHOR([EMAIL PROTECTED]);
@@ -1094,6 +1110,44 @@ megasas_service_aen(struct megasas_insta
megasas_return_cmd(instance, cmd);
}
+static struct megasas_instance *megasas_lookup_instance(u16 host_no)
+{
+ int i;
+
+ for (i = 0; i megasas_mgmt_info.max_index; i++) {
+ if ((megasas_mgmt_info.instance[i])
+ (megasas_mgmt_info.instance[i]-host-host_no
+ == host_no))
+ return megasas_mgmt_info.instance[i];
+ }
+
+ return NULL;
+}
+
+static int megasas_slave_alloc(struct scsi_device *sdev)
+{
+ struct megasas_instance *instance;
+ int tmp_fastload = fast_load;
+
+ instance = megasas_lookup_instance(sdev-host-host_no);
+
+ if (tmp_fastload sdev-channel MEGASAS_MAX_PD_CHANNELS) {
+ if ((sdev-id == MEGASAS_MAX_DEV_PER_CHANNEL -1)
+ (sdev-channel == MEGASAS_MAX_PD_CHANNELS - 1)) {
+
+ /*
+* If fast load option was set and scan for last device is
+* over, reset the fast_load flag so that during a possible
+* next scan, devices can be made available
+*/
+ fast_load = 0;
+ }
+ return -ENXIO;
+ }
+
+ return 0;
+}
+
/*
* Scsi host template for megaraid_sas driver
*/
@@ -1103,6 +1157,7 @@ static struct scsi_host_template megasas
.name = LSI Logic SAS based MegaRAID driver,
.proc_name = megaraid_sas,
.slave_configure = megasas_slave_configure,
+ .slave_alloc = megasas_slave_alloc,
.queuecommand = megasas_queue_command,
.eh_device_reset_handler = megasas_reset_device,
.eh_bus_reset_handler = megasas_reset_bus_host,
@@ -2961,20 +3016,6 @@ megasas_mgmt_fw_ioctl(struct megasas_ins
return error;
}
-static struct megasas_instance *megasas_lookup_instance(u16 host_no)
-{
- int i;
-
- for (i = 0; i megasas_mgmt_info.max_index; i++) {
-
- if ((megasas_mgmt_info.instance[i])
- (megasas_mgmt_info.instance[i]-host-host_no == host_no))
- return megasas_mgmt_info.instance[i];
- }
-
- return NULL;
-}
-
static int megasas_mgmt_ioctl_fw(struct file *file, unsigned long arg)
{
struct megasas_iocpacket __user *user_ioc =
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8] scsi: megaraid_sas - add module param max_sectors, cmd_per_lun
Adding module parameters to configure max sectors per request # of cmds per
lun.
Signed-off-by: Bo Yang [EMAIL PROTECTED]
---
drivers/scsi/megaraid/megaraid_sas.c | 68 -
drivers/scsi/megaraid/megaraid_sas.h |2
2 files changed, 68 insertions(+), 2 deletions(-)
diff -uprN linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c
linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.c
--- linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c 2007-10-01
00:14:29.0 -0700
+++ linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.c 2007-10-01
02:15:16.0 -0700
@@ -62,6 +62,23 @@ MODULE_PARM_DESC(fast_load,
megasas: Faster loading of the driver, skips physical devices! \
(default = 0));
+/*
+ * Number of sectors per IO command will be set in megasas_init_mfi
+ * if user does not provide
+ */
+static unsigned int max_sectors;
+module_param_named(max_sectors, max_sectors, int, 0);
+MODULE_PARM_DESC(max_sectors,
+ Maximum number of sectors per IO command);
+
+/*
+ * Number of cmds per logical unit
+ */
+static unsigned int cmd_per_lun = MEGASAS_DEFAULT_CMD_PER_LUN;
+module_param_named(cmd_per_lun, cmd_per_lun, int, 0);
+MODULE_PARM_DESC(cmd_per_lun,
+ Maximum number of commands per logical unit (default=128));
+
MODULE_LICENSE(GPL);
MODULE_VERSION(MEGASAS_VERSION);
MODULE_AUTHOR([EMAIL PROTECTED]);
@@ -1148,6 +1165,24 @@ static int megasas_slave_alloc(struct sc
return 0;
}
+static ssize_t
+megasas_sysfs_max_sectors_read(struct class_device *cdev, char *buf)
+{
+ struct Scsi_Host *shost = class_to_shost(cdev);
+ struct megasas_instance *instance =
+ (struct megasas_instance *)shost-hostdata;
+
+ return snprintf(buf, 8, %u\n, instance-max_sectors_per_req);
+}
+
+CLASS_DEVICE_ATTR(max_sectors, S_IRUGO, megasas_sysfs_max_sectors_read,
+ NULL);
+
+static struct class_device_attribute *megasas_shost_attrs[] = {
+ class_device_attr_max_sectors,
+ NULL,
+};
+
/*
* Scsi host template for megaraid_sas driver
*/
@@ -1165,6 +1200,7 @@ static struct scsi_host_template megasas
.eh_timed_out = megasas_reset_timer,
.bios_param = megasas_bios_param,
.use_clustering = ENABLE_CLUSTERING,
+ .shost_attrs = megasas_shost_attrs,
};
/**
@@ -2310,15 +2346,43 @@ static int megasas_io_attach(struct mega
struct Scsi_Host *host = instance-host;
/*
-* Export parameters required by SCSI mid-layer
+* Export host parameters required by SCSI
+* mid-layer
*/
host-irq = instance-pdev-irq;
host-unique_id = instance-unique_id;
host-can_queue = instance-max_fw_cmds - MEGASAS_INT_CMDS;
host-this_id = instance-init_id;
host-sg_tablesize = instance-max_num_sge;
+
+ /*
+* Check if the module parameter value for max_sectors can be used
+*/
+ if (max_sectors max_sectors = instance-max_sectors_per_req)
+ instance-max_sectors_per_req = max_sectors;
+ else if (max_sectors) {
+ printk(KERN_INFO
+ megasas: max_sectors should be 0 and = %d\n,
+ instance-max_sectors_per_req);
+ }
+
host-max_sectors = instance-max_sectors_per_req;
- host-cmd_per_lun = 128;
+
+ /*
+* Check if the module parameter value for cmd_per_lun can be used
+*/
+ instance-cmd_per_lun = MEGASAS_DEFAULT_CMD_PER_LUN;
+ if (cmd_per_lun cmd_per_lun = MEGASAS_DEFAULT_CMD_PER_LUN)
+ instance-cmd_per_lun = cmd_per_lun;
+ else
+ printk(KERN_INFO megasas: cmd_per_lun should be 0 and
+ = %d\n, MEGASAS_DEFAULT_CMD_PER_LUN);
+
+ host-cmd_per_lun = instance-cmd_per_lun;
+
+ printk(KERN_DEBUG megasas: max_sectors : 0x%x, cmd_per_lun : 0x%x\n,
+ instance-max_sectors_per_req, instance-cmd_per_lun);
+
host-max_channel = MEGASAS_MAX_CHANNELS - 1;
host-max_id = MEGASAS_MAX_DEV_PER_CHANNEL;
host-max_lun = MEGASAS_MAX_LUN;
diff -uprN linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.h
linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.h
--- linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.h 2007-10-01
00:03:59.0 -0700
+++ linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.h 2007-10-01
00:03:59.0 -0700
@@ -537,6 +537,7 @@ struct megasas_ctrl_info {
#define MEGASAS_DEFAULT_INIT_ID-1
#define MEGASAS_MAX_LUN8
#define MEGASAS_MAX_LD 64
+#define MEGASAS_DEFAULT_CMD_PER_LUN128
#define MEGASAS_DBG_LVL1
@@ -1080,6 +1081,7 @@ struct megasas_instance {
u16 max_num_sge;
u16 max_fw_cmds;
u32 max_sectors_per_req;
+ u32 cmd_per_lun;
struct
[PATCH 4/8] scsi: megaraid_sas - check max_sgl reported by FW for setting max_sectors_per_req
1. Setting the max_sectors_per_req based on max SGL supported by the FW. Prior
versions calculated
this value from controller info's max_sectors_1, max_sectors_2. For
certain controllers/FW,
this was resulting in a value greater than max SGL supported by the FW.
Now we take the min
of max sgl from FW and max_sectors calculation.
2. Increased MFI_POLL_TIMEOUT_SECS to 60 seconds from 10. FW may take a max of
60 seconds to
respond to the INIT cmd.
Signed-off-by: Bo Yang [EMAIL PROTECTED]
---
drivers/scsi/megaraid/megaraid_sas.c | 14 +-
drivers/scsi/megaraid/megaraid_sas.h |2 +-
2 files changed, 10 insertions(+), 6 deletions(-)
diff -uprN linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c
linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.c
--- linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c 2007-10-01
02:42:25.0 -0700
+++ linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.c 2007-10-01
05:19:06.0 -0700
@@ -1979,6 +1979,7 @@ static int megasas_init_mfi(struct megas
u32 reply_q_sz;
u32 max_sectors_1;
u32 max_sectors_2;
+ u32 tmp_sectors;
struct megasas_register_set __iomem *reg_set;
struct megasas_ctrl_info *ctrl_info;
/*
@@ -2071,17 +2072,20 @@ static int megasas_init_mfi(struct megas
* Note that older firmwares ( FW ver 30) didn't report information
* to calculate max_sectors_1. So the number ended up as zero always.
*/
+ tmp_sectors = 0;
if (ctrl_info !megasas_get_ctrl_info(instance, ctrl_info)) {
max_sectors_1 = (1 ctrl_info-stripe_sz_ops.min) *
ctrl_info-max_strips_per_io;
max_sectors_2 = ctrl_info-max_request_size;
- instance-max_sectors_per_req = (max_sectors_1 max_sectors_2)
- ? max_sectors_1 : max_sectors_2;
- } else
- instance-max_sectors_per_req = instance-max_num_sge *
- PAGE_SIZE / 512;
+ tmp_sectors = min_t(u32, max_sectors_1 , max_sectors_2);
+ }
+
+ instance-max_sectors_per_req = instance-max_num_sge *
+ PAGE_SIZE / 512;
+ if (tmp_sectors (instance-max_sectors_per_req tmp_sectors))
+ instance-max_sectors_per_req = tmp_sectors;
kfree(ctrl_info);
diff -uprN linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.h
linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.h
--- linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.h 2007-10-01
00:03:59.0 -0700
+++ linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.h 2007-10-01
00:03:59.0 -0700
@@ -572,7 +572,7 @@ struct megasas_ctrl_info {
#define IS_DMA64 (sizeof(dma_addr_t) == 8)
#define MFI_OB_INTR_STATUS_MASK0x0002
-#define MFI_POLL_TIMEOUT_SECS 10
+#define MFI_POLL_TIMEOUT_SECS 60
#define MFI_REPLY_1078_MESSAGE_INTERRUPT 0x8000
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8] scsi: megaraid_sas - using unsigned long for sense_buff ptr
MegaRAID utilities expect sense_buff to be of type unsigned long.
Signed-off-by: Bo Yang [EMAIL PROTECTED]
---
drivers/scsi/megaraid/megaraid_sas.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff -uprN linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c
linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.c
--- linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c 2007-10-01
05:20:03.0 -0700
+++ linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.c 2007-10-02
22:40:22.0 -0700
@@ -2942,6 +2942,7 @@ megasas_mgmt_fw_ioctl(struct megasas_ins
void *sense = NULL;
dma_addr_t sense_handle;
u32 *sense_ptr;
+ unsigned long *sense_buff;
memset(kbuff_arr, 0, sizeof(kbuff_arr));
@@ -3046,14 +3047,16 @@ megasas_mgmt_fw_ioctl(struct megasas_ins
*/
if (ioc-sense_len) {
/*
-* sense_ptr points to the location that has the user
+* sense_buff points to the location that has the user
* sense buffer address
*/
- sense_ptr = (u32 *) ((unsigned long)ioc-frame.raw +
-ioc-sense_off);
+ sense_buff = (unsigned long *) ((unsigned long)ioc-frame.raw +
+ ioc-sense_off);
- if (copy_to_user((void __user *)((unsigned long)(*sense_ptr)),
-sense, ioc-sense_len)) {
+ if (copy_to_user((void __user *)(unsigned long)(*sense_buff),
+ sense, ioc-sense_len)) {
+ printk(KERN_ERR megasas: Failed to copy out to user
+ sense data\n);
error = -EFAULT;
goto out;
}
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] scsi: megaraid_sas - call cmd completion from reset
Driver will call cmd completion routine from Reset path without waiting for cmd
completion from isr context.
Signed-off-by: Bo Yang [EMAIL PROTECTED]
---
drivers/scsi/megaraid/megaraid_sas.c | 122 +
drivers/scsi/megaraid/megaraid_sas.h |2
2 files changed, 70 insertions(+), 54 deletions(-)
diff -uprN linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c
linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.c
--- linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c 2007-10-02
22:41:39.0 -0700
+++ linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.c 2007-10-02
23:32:05.0 -0700
@@ -109,6 +109,10 @@ static DEFINE_MUTEX(megasas_async_queue_
static u32 megasas_dbg_lvl;
+static void
+megasas_complete_cmd(struct megasas_instance *instance, struct megasas_cmd
*cmd,
+u8 alt_status);
+
/**
* megasas_get_cmd - Get a command from the free pool
* @instance: Adapter soft state
@@ -919,6 +923,64 @@ static int megasas_slave_configure(struc
}
/**
+ * megasas_complete_cmd_dpc - Returns FW's controller structure
+ * @instance_addr: Address of adapter soft state
+ *
+ * Tasklet to complete cmds
+ */
+static void megasas_complete_cmd_dpc(unsigned long instance_addr)
+{
+ u32 producer;
+ u32 consumer;
+ u32 context;
+ struct megasas_cmd *cmd;
+ struct megasas_instance *instance =
+ (struct megasas_instance *)instance_addr;
+ unsigned long flags;
+
+ /* If we have already declared adapter dead, donot complete cmds */
+ if (instance-hw_crit_error)
+ return;
+
+ spin_lock_irqsave(instance-completion_lock, flags);
+
+ producer = *instance-producer;
+ consumer = *instance-consumer;
+
+ while (consumer != producer) {
+ context = instance-reply_queue[consumer];
+
+ cmd = instance-cmd_list[context];
+
+ megasas_complete_cmd(instance, cmd, DID_OK);
+
+ consumer++;
+ if (consumer == (instance-max_fw_cmds + 1)) {
+ consumer = 0;
+ }
+ }
+
+ *instance-consumer = producer;
+
+ spin_unlock_irqrestore(instance-completion_lock, flags);
+
+ /*
+* Check if we can restore can_queue
+*/
+ if (instance-flag MEGASAS_FW_BUSY
+time_after(jiffies, instance-last_time + 5 * HZ)
+atomic_read(instance-fw_outstanding) 17) {
+
+ spin_lock_irqsave(instance-host-host_lock, flags);
+ instance-flag = ~MEGASAS_FW_BUSY;
+ instance-host-can_queue =
+ instance-max_fw_cmds - MEGASAS_INT_CMDS;
+
+ spin_unlock_irqrestore(instance-host-host_lock, flags);
+ }
+}
+
+/**
* megasas_wait_for_outstanding - Wait for all outstanding cmds
* @instance: Adapter soft state
*
@@ -941,6 +1003,11 @@ static int megasas_wait_for_outstanding(
if (!(i % MEGASAS_RESET_NOTICE_INTERVAL)) {
printk(KERN_NOTICE megasas: [%2d]waiting for %d
commands to complete\n,i,outstanding);
+ /*
+* Call cmd completion routine. Cmd to be
+* be completed directly without depending on isr.
+*/
+ megasas_complete_cmd_dpc((unsigned long)instance);
}
msleep(1000);
@@ -1839,60 +1906,6 @@ megasas_get_ctrl_info(struct megasas_ins
}
/**
- * megasas_complete_cmd_dpc - Returns FW's controller structure
- * @instance_addr: Address of adapter soft state
- *
- * Tasklet to complete cmds
- */
-static void megasas_complete_cmd_dpc(unsigned long instance_addr)
-{
- u32 producer;
- u32 consumer;
- u32 context;
- struct megasas_cmd *cmd;
- struct megasas_instance *instance = (struct megasas_instance
*)instance_addr;
- unsigned long flags;
-
- /* If we have already declared adapter dead, donot complete cmds */
- if (instance-hw_crit_error)
- return;
-
- producer = *instance-producer;
- consumer = *instance-consumer;
-
- while (consumer != producer) {
- context = instance-reply_queue[consumer];
-
- cmd = instance-cmd_list[context];
-
- megasas_complete_cmd(instance, cmd, DID_OK);
-
- consumer++;
- if (consumer == (instance-max_fw_cmds + 1)) {
- consumer = 0;
- }
- }
-
- *instance-consumer = producer;
-
- /*
-* Check if we can restore can_queue
-*/
- if (instance-flag MEGASAS_FW_BUSY
-time_after(jiffies, instance-last_time + 5 * HZ)
-
Re: generating a Linux WWN?
Luben Tuikov wrote: What is needed is persistence, regardless of reboots of what OS is running on the host CPU/system. SAS WWNs are properties of the SAS target/initiator port, they are not properties of when the host system was booted, or what OS is running on it. As part of the previously described schemes, the admin is certainly allowed to choose an option (manual WWN specification) that enables an external system of persistance. But such a system should not be a /requirement/, when all an admin might want to do is simply get their card working. The admin knows whats best for their site, and may choose. Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/8] scsi: megaraid_sas - Update version and changelog
Update version and changelog. Updated LSI Logic to new name LSI Signed-off-by: Bo Yang [EMAIL PROTECTED] --- Documentation/scsi/ChangeLog.megaraid_sas | 160 drivers/scsi/megaraid/megaraid_sas.c | 10 - drivers/scsi/megaraid/megaraid_sas.h |8 - 3 files changed, 169 insertions(+), 9 deletions(-) diff -uprN linux-2.6.22_orig/Documentation/scsi/ChangeLog.megaraid_sas linux-2.6.22_new/Documentation/scsi/ChangeLog.megaraid_sas --- linux-2.6.22_orig/Documentation/scsi/ChangeLog.megaraid_sas 2007-10-01 00:03:59.0 -0700 +++ linux-2.6.22_new/Documentation/scsi/ChangeLog.megaraid_sas 2007-10-01 00:03:59.0 -0700 @@ -1,3 +1,163 @@ +1 Release Date: Thur. Sep. 27 10:09:32 PDT 2007 - + (emaild-id:[EMAIL PROTECTED]) + Sumant Patro + Bo Yang + +2 Current Version : 00.00.03.16-rc1 +3 Older Version : 00.00.03.15 + +1. Increased MFI_POLL_TIMEOUT_SECS to 60 seconds from 10. FW may take a max of 60 seconds to + respond to the INIT cmd. + +1 Release Date: Fri. Sep. 07 16:30:43 PST 2007 - + (emaild-id:[EMAIL PROTECTED]) + Sumant Patro + Bo Yang + +2 Current Version : 00.00.03.15 +3 Older Version : 00.00.03.14 + +1. Added module parameter poll_mode_io to support for polling (reduced interrupt operation). + In this mode, IO completion interrupts are delayed. At the end of initiating IOs, + the driver schedules for cmd completion if there are pending cmds to be completed. + A timer-based interrupt has also been added to prevent IO completion processing from + being delayed indefinitely in the case that no new IOs are initiated. + +1 Release Date: Fri. Sep. 07 16:30:43 PST 2007 - + (emaild-id:[EMAIL PROTECTED]) + Sumant Patro + Bo Yang + +2 Current Version : 00.00.03.14 +3 Older Version : 00.00.03.13 + +1. Setting the max_sectors_per_req based on max SGL supported by the FW. Prior versions calculated + this value from controller info (max_sectors_1, max_sectors_2). For certain controllers/FW, + this was resulting in a value greater than max SGL supported by the FW. Issue was first + reported by users running LUKS+XFS with megaraid_sas. + Thanks to RB for providing the logs and duplication steps that helped to get to the root + cause of the issue. +2. Increased MFI_POLL_TIMEOUT_SECS to 60 seconds from 10. FW may take a max of 60 seconds to + respond to the INIT cmd. + +1 Release Date: Fri. June. 15 16:30:43 PST 2007 - + (emaild-id:[EMAIL PROTECTED]) + Sumant Patro + Bo Yang + +2 Current Version : 00.00.03.13 +3 Older Version : 00.00.03.12 + +1. Added the megasas_reset_timer routine to intercept cmd timeout and throttle io. + +On Fri, 2007-03-16 at 16:44 -0600, James Bottomley wrote: +It looks like megaraid_sas at least needs this to throttle its commands + as they begin to time out. The code keeps the existing transport + template use of eh_timed_out (and allows the transport to override the + host if they both have this callback). + + James + +1 Release Date: Sat May. 12 16:30:43 PST 2007 - + (emaild-id:[EMAIL PROTECTED]) + Sumant Patro + Bo Yang + +2 Current Version : 00.00.03.12 +3 Older Version : 00.00.03.11 + +1. When MegaSAS driver receives reset call from OS, driver waits in reset +routine for max 3 minutes for all pending command completion. Now driver will +call completion routine every 5 seconds from the reset routine instead of +waiting for depending on cmd completion from isr path. + +1 Release Date: Mon Apr. 30 10:25:52 PST 2007 - + (emaild-id:[EMAIL PROTECTED]) + Sumant Patro + Bo Yang + +2 Current Version : 00.00.03.11 +3 Older Version : 00.00.03.09 + + 1. Following module parameters added - + fast_load: Faster loading of the driver, skips physical devices scanning thereby + reducing the time to load driver. + cmd_per_lun: Maximum number of commands per logical unit + max_sectors: Maximum number of sectors per IO command + 2. Memory Manager for IOCTL removed for 2.6 kernels. + pci_alloc_consistent replaced by dma_alloc_coherent. With this + change there is no need of memory manager in the driver code + + On Wed, 2007-02-07 at 13:30 -0800, Andrew Morton wrote: +I suspect all this horror is due to stupidity in the DMA API. + +pci_alloc_consistent() just goes and assumes GFP_ATOMIC, whereas +the caller (megasas_mgmt_fw_ioctl) would have been perfectly happy +to use GFP_KERNEL. + +I bet this
Re: [PATCH 3/8] scsi: megaraid_sas - add module param max_sectors, cmd_per_lun
On Mon, 01 Oct 2007 11:51:48 -0400 bo yang wrote: Adding module parameters to configure max sectors per request # of cmds per lun. Signed-off-by: Bo Yang [EMAIL PROTECTED] --- drivers/scsi/megaraid/megaraid_sas.c | 68 - drivers/scsi/megaraid/megaraid_sas.h |2 2 files changed, 68 insertions(+), 2 deletions(-) diff -uprN linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.c --- linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c2007-10-01 00:14:29.0 -0700 +++ linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.c 2007-10-01 02:15:16.0 -0700 @@ -62,6 +62,23 @@ MODULE_PARM_DESC(fast_load, megasas: Faster loading of the driver, skips physical devices! \ (default = 0)); +/* + * Number of sectors per IO command will be set in megasas_init_mfi + * if user does not provide + */ +static unsigned int max_sectors; +module_param_named(max_sectors, max_sectors, int, 0); +MODULE_PARM_DESC(max_sectors, + Maximum number of sectors per IO command); Are you sure that you want these parameters hidden (permission = 0) instead of readable via sysfs? (same applies to the fast_load parameter patch also) +/* + * Number of cmds per logical unit + */ +static unsigned int cmd_per_lun = MEGASAS_DEFAULT_CMD_PER_LUN; +module_param_named(cmd_per_lun, cmd_per_lun, int, 0); +MODULE_PARM_DESC(cmd_per_lun, + Maximum number of commands per logical unit (default=128)); + MODULE_LICENSE(GPL); MODULE_VERSION(MEGASAS_VERSION); MODULE_AUTHOR([EMAIL PROTECTED]); --- ~Randy - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] add sg segment limitation info to device structure
On Wed, Oct 03, 2007 at 11:19:22PM +0900, FUJITA Tomonori wrote:
On Tue, 2 Oct 2007 09:44:13 -0700
Greg KH [EMAIL PROTECTED] wrote:
On Tue, Oct 02, 2007 at 09:25:34AM -0600, Matthew Wilcox wrote:
On Tue, Oct 02, 2007 at 05:23:39PM +0200, Kay Sievers wrote:
Just looking at the number of devices, it seems that allocating it
dynamically would be the better deal. We allocate the name of every
kobject dynamically today, so I guess it's fine to do that with the
DMA data too.
But we don't need to allocate it dynamically. We can embed it in the
pci_dev, eisa_dev, zorro_dev, mca_dev and parisc_device.
But then you run into the issue that James pointed out originally.
Anyway, I don't care which, let's see some patches :)
How about this (based on James' proposal)?
- Currently, there are only max_segment_size and segment_boundary_mask
in struct device_dma_parameters (I'll add segment_boundary_mask
support later after I finish the iommu part). We'll move more dma
stuff in struct device (like dma_mask) to struct device_dma_parameters
later (needs some cleanups before that).
- New accessors for the dma parameters are added. So we can easily
change where to place struct device_dma_parameters in the future.
- the default max_segment_size is set to 64K, same to the block
layer's default value.
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 37c00f6..c93ebe8 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1392,6 +1392,13 @@ pci_set_consistent_dma_mask(struct pci_dev *dev, u64
mask)
}
#endif
+#ifndef HAVE_ARCH_PCI_SET_DMA_MAX_SEGMENT_SIZE
+int pci_set_dma_max_seg_size(struct pci_dev *dev, unsigned int size)
+{
+ return dma_set_max_seg_size(dev-dev, size);
+}
+#endif
+
/**
* pcix_get_max_mmrbc - get PCI-X maximum designed memory read byte count
* @dev: PCI device to query
@@ -1624,6 +1631,7 @@ EXPORT_SYMBOL(pci_clear_mwi);
EXPORT_SYMBOL_GPL(pci_intx);
EXPORT_SYMBOL(pci_set_dma_mask);
EXPORT_SYMBOL(pci_set_consistent_dma_mask);
+EXPORT_SYMBOL(pci_set_dma_max_seg_size);
EXPORT_SYMBOL(pci_assign_resource);
EXPORT_SYMBOL(pci_find_parent_resource);
EXPORT_SYMBOL(pci_select_bars);
Export the symbol right next to the function, that way the #ifdef
doesn't have to be duplicated.
other than that minor problem, this looks good to me. James, any
objection to this?
thanks,
greg k-h
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: generating a Linux WWN?
From: Luben Tuikov [EMAIL PROTECTED] Date: Wed, 3 Oct 2007 15:08:48 -0700 (PDT) Your want to get their card working way of view is very simplistic to justify generating and assigning SAS WWN in the kernel. This is the job of the manufacturer/packager, not the host OS. When you are thousands of miles away from the data center and lose all of your storage and therefore can't boot correctly because the WWN info is corrupted, you won't have this unbelievably fascist attitude about this problem. Give people an _OPTION_! This is about as anti-social as when the Intel folks refused to themselves put in a driver option to try to use an eepro100 card even if the EEPROM was corrupted and had a bad checksum. For the person who hits this, it's a big issue to have a way to still try to bring things up. If you don't provide this, you want people to suffer more than necessary when something goes wrong, and that by definition makes you an asshole. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: generating a Linux WWN?
--- Jeff Garzik [EMAIL PROTECTED] wrote: Luben Tuikov wrote: What is needed is persistence, regardless of reboots of what OS is running on the host CPU/system. SAS WWNs are properties of the SAS target/initiator port, they are not properties of when the host system was booted, or what OS is running on it. As part of the previously described schemes, the admin is certainly allowed to choose an option (manual WWN specification) that enables an external system of persistance. But such a system should not be a /requirement/, when all an admin might want to do is simply get their card working. It *is* a requirement, in fact at all levels of the product. How would you query the storage domain (at boot time mind you) that no such WWN exists, and/or will not exist when another storage component is connected to or comes online, if you generated it in the kernel? SAS ports not having a WWN as part of the MS/NVRAM is an *exception*, and a bad one at that. The driver should just complain and not bring up the HA. Your want to get their card working way of view is very simplistic to justify generating and assigning SAS WWN in the kernel. This is the job of the manufacturer/packager, not the host OS. Luben The admin knows whats best for their site, and may choose. Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: 2.6.23-rc9 boot failure (megaraid?)
-Original Message-
From: FUJITA Tomonori [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 02, 2007 5:01 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Patro, Sumant; DL-MegaRAID
Linux; linux-scsi@vger.kernel.org
Subject: Re: 2.6.23-rc9 boot failure (megaraid?)
On Tue, 02 Oct 2007 15:38:13 -0500
James Bottomley [EMAIL PROTECTED] wrote:
On Tue, 2007-10-02 at 20:15 +0200, Adrian Bunk wrote:
Cc's added, the complete bug report is at
http://lkml.org/lkml/2007/10/2/243
On Tue, Oct 02, 2007 at 12:48:26PM -0400, Burton Windle wrote:
2.6.23-rc9 fails to boot for me; 2.6.22.9 works fine.
System is a Dell Poweredge with PERC 2/DC with RAID1 volume.
...
Thanks for your report.
Diff'ing the dmesg's shows:
-- snip --
scsi0: scanning scsi channel 4 [P0] for physical devices.
scsi0: scanning scsi channel 5 [P1] for physical devices.
st: Version 20070203, fixed bufsize 32768, s/g segs 256 -sd
0:0:0:0: [sda] 17547264 512-byte hardware sectors (8984 MB)
+sd 0:0:0:0: [sda] Sector size 0 reported, assuming 512.
+sd 0:0:0:0: [sda] 1 512-byte hardware sectors (0 MB)
sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Asking
for cache data failed sd 0:0:0:0: [sda] Assuming drive
cache: write
through -sd 0:0:0:0: [sda] 17547264 512-byte hardware
sectors (8984
MB)
+sd 0:0:0:0: [sda] Sector size 0 reported, assuming 512.
+sd 0:0:0:0: [sda] 1 512-byte hardware sectors (0 MB)
sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Asking
for cache data failed sd 0:0:0:0: [sda] Assuming drive
cache: write
through
sda: sda1
+ sda: p1 exceeds device capacity
-- snip --
- case MEGA_BULK_DATA:
- if (scb-cmd-use_sg == 0)
- length = scb-cmd-request_bufflen;
- else {
- struct scatterlist *sgl =
- (struct scatterlist
*)scb-cmd-request_buffer;
- length = sgl-length;
- }
- pci_unmap_page(adapter-dev, scb-dma_h_bulkdata,
-length, scb-dma_direction);
- break;
-
This is the problem piece I think. We've reintroduced a
very old bug:
commit 51c928c34fa7cff38df584ad01de988805877dba
Author: James Bottomley [EMAIL PROTECTED]
Date: Sat Oct 1 09:38:05 2005 -0500
[SCSI] Legacy MegaRAID: Fix READ CAPACITY
Some Legacy megaraid cards can't actually cope with the
scatter/gather
version of the READ CAPACITY command (which is what we
now send them
since altering all SCSI internal I/O to go via the
block layer). Fix
this (and a few other broken megaraid driver
assumptions) by sending
the non-sg version of the command if the sg list only
has a single
element.
Signed-off-by: James Bottomley [EMAIL PROTECTED]
So what we have to do is put back the check for use_sg == 1
and send
that as a bulk transfer command.
Sorry about this. Can this fix the problem?
Thanks,
diff --git a/drivers/scsi/megaraid.c
b/drivers/scsi/megaraid.c index 3907f67..da56163 100644
--- a/drivers/scsi/megaraid.c
+++ b/drivers/scsi/megaraid.c
@@ -1753,6 +1753,14 @@ mega_build_sglist(adapter_t *adapter,
scb_t *scb, u32 *buf, u32 *len)
*len = 0;
+ if (scsi_sg_count(cmd) == 1 !adapter-has_64bit_addr) {
+ sg = scsi_sglist(cmd);
+ scb-dma_h_bulkdata = sg_dma_address(sg);
+ *buf = (u32)scb-dma_h_bulkdata;
+ *len = sg_dma_len(sg);
+ return 0;
+ }
+
scsi_for_each_sg(cmd, sg, sgcnt, idx) {
if (adapter-has_64bit_addr) {
scb-sgl64[idx].address = sg_dma_address(sg);
With this patch I see the correct logical disk size reported.
Thanks.
Sumant
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: 2.6.23-rc9 boot failure (megaraid?)
On Wed, 3 Oct 2007 17:32:55 -0600
Patro, Sumant [EMAIL PROTECTED] wrote:
-Original Message-
From: FUJITA Tomonori [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 02, 2007 5:01 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Patro, Sumant; DL-MegaRAID
Linux; linux-scsi@vger.kernel.org
Subject: Re: 2.6.23-rc9 boot failure (megaraid?)
On Tue, 02 Oct 2007 15:38:13 -0500
James Bottomley [EMAIL PROTECTED] wrote:
On Tue, 2007-10-02 at 20:15 +0200, Adrian Bunk wrote:
Cc's added, the complete bug report is at
http://lkml.org/lkml/2007/10/2/243
On Tue, Oct 02, 2007 at 12:48:26PM -0400, Burton Windle wrote:
2.6.23-rc9 fails to boot for me; 2.6.22.9 works fine.
System is a Dell Poweredge with PERC 2/DC with RAID1 volume.
...
Thanks for your report.
Diff'ing the dmesg's shows:
-- snip --
scsi0: scanning scsi channel 4 [P0] for physical devices.
scsi0: scanning scsi channel 5 [P1] for physical devices.
st: Version 20070203, fixed bufsize 32768, s/g segs 256 -sd
0:0:0:0: [sda] 17547264 512-byte hardware sectors (8984 MB)
+sd 0:0:0:0: [sda] Sector size 0 reported, assuming 512.
+sd 0:0:0:0: [sda] 1 512-byte hardware sectors (0 MB)
sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Asking
for cache data failed sd 0:0:0:0: [sda] Assuming drive
cache: write
through -sd 0:0:0:0: [sda] 17547264 512-byte hardware
sectors (8984
MB)
+sd 0:0:0:0: [sda] Sector size 0 reported, assuming 512.
+sd 0:0:0:0: [sda] 1 512-byte hardware sectors (0 MB)
sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Asking
for cache data failed sd 0:0:0:0: [sda] Assuming drive
cache: write
through
sda: sda1
+ sda: p1 exceeds device capacity
-- snip --
- case MEGA_BULK_DATA:
- if (scb-cmd-use_sg == 0)
- length = scb-cmd-request_bufflen;
- else {
- struct scatterlist *sgl =
- (struct scatterlist
*)scb-cmd-request_buffer;
- length = sgl-length;
- }
- pci_unmap_page(adapter-dev, scb-dma_h_bulkdata,
- length, scb-dma_direction);
- break;
-
This is the problem piece I think. We've reintroduced a
very old bug:
commit 51c928c34fa7cff38df584ad01de988805877dba
Author: James Bottomley [EMAIL PROTECTED]
Date: Sat Oct 1 09:38:05 2005 -0500
[SCSI] Legacy MegaRAID: Fix READ CAPACITY
Some Legacy megaraid cards can't actually cope with the
scatter/gather
version of the READ CAPACITY command (which is what we
now send them
since altering all SCSI internal I/O to go via the
block layer). Fix
this (and a few other broken megaraid driver
assumptions) by sending
the non-sg version of the command if the sg list only
has a single
element.
Signed-off-by: James Bottomley [EMAIL PROTECTED]
So what we have to do is put back the check for use_sg == 1
and send
that as a bulk transfer command.
Sorry about this. Can this fix the problem?
Thanks,
diff --git a/drivers/scsi/megaraid.c
b/drivers/scsi/megaraid.c index 3907f67..da56163 100644
--- a/drivers/scsi/megaraid.c
+++ b/drivers/scsi/megaraid.c
@@ -1753,6 +1753,14 @@ mega_build_sglist(adapter_t *adapter,
scb_t *scb, u32 *buf, u32 *len)
*len = 0;
+ if (scsi_sg_count(cmd) == 1 !adapter-has_64bit_addr) {
+ sg = scsi_sglist(cmd);
+ scb-dma_h_bulkdata = sg_dma_address(sg);
+ *buf = (u32)scb-dma_h_bulkdata;
+ *len = sg_dma_len(sg);
+ return 0;
+ }
+
scsi_for_each_sg(cmd, sg, sgcnt, idx) {
if (adapter-has_64bit_addr) {
scb-sgl64[idx].address = sg_dma_address(sg);
With this patch I see the correct logical disk size reported.
Thanks.
Great, thanks for testing!
Can you try the following patch instead of the above patch?
http://marc.info/?l=linux-scsim=119137033016550w=2
I know the changes are pretty trivial and it should work...
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: generating a Linux WWN?
--- David Miller [EMAIL PROTECTED] wrote: From: Luben Tuikov [EMAIL PROTECTED] Date: Wed, 3 Oct 2007 15:08:48 -0700 (PDT) Your want to get their card working way of view is very simplistic to justify generating and assigning SAS WWN in the kernel. This is the job of the manufacturer/packager, not the host OS. When you are thousands of miles away from the data center and lose all of your storage and therefore can't boot correctly because the WWN info is corrupted, you won't have this unbelievably fascist attitude about this problem. Give people an _OPTION_! This is about as anti-social as when the Intel folks refused to themselves put in a driver option to try to use an eepro100 card even if the EEPROM was corrupted and had a bad checksum. For the person who hits this, it's a big issue to have a way to still try to bring things up. If you don't provide this, you want people to suffer more than necessary when something goes wrong, and that by definition makes you an asshole. No, not all. If the MS/NVRAM is corrupted (becomes corrupted) then it is better for the admin to see that the system wouldn't boot or that the storage domain is not visible (if the system doesn't boot from it), and provide a sample WWN at kernel boot line or module load time, just to connect to the storage network. But having a WWN generator in the kernel, although not terribly difficult to write, makes it possible to create an inconsistent storage domain. It is that possibility which troubles me, due to the intention of SAS WWNs. I guess much of this argument doesn't really matter, since most SAS HA would really be a ROC, and as thus much more would need to happen before the HA is useable, than just having a MS/NVRAM with the WWN. Here is what modinfo aic94xx.ko (the version I maintain) says: parm: sas_addr_str: Provide a SAS address for a single host adapter. This is for testing only! You should not need to provide this! Luben - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] qla2xxx: add target mode support
On Wed, 03 Oct 2007 12:47:26 -0700 Seokmann Ju [EMAIL PROTECTED] wrote: FUJITA Tomonori wrote: On Mon, 01 Oct 2007 11:00:44 -0700 Seokmann Ju [EMAIL PROTECTED] wrote: atl-01:/lib/modules/2.6.23-rc3-smp-tgt/kernel/drivers/scsi/qla2xxx # tgtadm --lld fc --mode target --op show Target 1: volume1 System information: Driver: fc Status: running I_T nexus information: LUN information: LUN: 0 Type: controller SCSI ID: deadbeaf1:0 SCSI SN: beaf10 Size: 0 Online: No Poweron/Reset: Yes Removable media: No Backing store: No backing store ACL information: You successfully created a new target but failed to add a new logical unit (#1) to it (note that lun 0 was created automatically). Yes, I have noticed it. ./tgt/usr/tgtadm --lld fc --mode logicalunit --op new --tid 1 --lun 1 -b /var/tmp/lun1 We are try to add a regular file (/var/tmp/lun1) to the target and export it as a logical unit to initiators. Do you have /var/tmp/lun1? With the creation of an empty file, it started to display the lun1. --- atl-01:~ # tgtadm --lld fc --mode target --op show Target 1: tgt-vol1 System information: Driver: fc Status: running I_T nexus information: I_T nexus: f6fb6000 The target got an initiator. Can you setup a target first (all the initiators are shut down (or fc kernel modules in initiators hosts are unloaded). There is no I_T nexus in the show operation's output. Then you start initiator hosts (or load the kernel modules) and hopefully the initiator hots can see luns. LUN information: LUN: 0 Type: controller SCSI ID: deadbeaf1:0 SCSI SN: beaf10 Size: 0 Online: No Poweron/Reset: Yes Removable media: No Backing store: No backing store LUN: 1 Type: disk SCSI ID: deadbeaf1:1 SCSI SN: beaf11 Size: 0 Note 'Size: 0' line. Needs to use a non-empty file. Online: Yes Poweron/Reset: Yes Removable media: No Backing store: /var/tmp/lun1 ACL information: atl-01:~ # --- However, from the initiator, still not be able to see the target - from the lsscsi, no other devices (controller/virtual-disk) than those physical devices available on the fabric. Instead, the host with target-mode displays following messages, --- Oct 3 11:21:13 atl-01 kernel: q2t_it_nexus_response 1191: dff46400 0 Oct 3 11:21:13 atl-01 kernel: q2t_it_nexus_response 1191: dff46400 0 It means that user-space daemon (tgtd) sent a message that a new I_T nexus was created. If I understood correctly, the F/W on the host with target-mode should have gotten some SCSI commands from the host with initiator-mode by now. And those commands should have been forwarded to the target driver via the interrupt handler (qla24xx_intr_handler()). Yeah, I think so. Just for my learning, could you share with me which of the F/W version (on the target-mode QLogic FC HBA) you are using? qla2xxx :0a:02.0: QLogic Fibre Channel HBA Driver: 8.02.00-k2 QLogic QLA2340 - 133MHz PCI-X to 2Gb FC, Single Channel ISP2312: PCI-X (133 MHz) @ :0a:02.0 hdma-, host#=3, fw=3.03.20 IPX - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: generating a Linux WWN?
But having a WWN generator in the kernel, although not terribly difficult to write, makes it possible to create an inconsistent storage domain. It is that possibility which troubles me, due to the intention of SAS WWNs. But one should make sure that you *do* create a consistent storage domain. If you can seed the system with a couple dozen free WWNs for use when/if needed, why not? People are content to believe that UUID generation is sufficiently unique, and for the bit space it occupies that's probably a reasonable clain. But you can't jam that into the smaller bit space WWNs. For smaller bit spaces like 64 bit WWNs, you cannot, as you correctly point out, generate reliably unique numbers all by youself. The closest you could probably come is using a type 5 WWN with a known single OUI and then use seconds since January 1 2007 as a serial number in the 36 bit VID space that gives you about 8 years before it wraps- the likely collision rate here would be pretty low. A much better choice is to get real stamped serial number WWNs. I also hold with some of the other folks on this discussion that some of this is policy that the admin should be allowed to choose. After they've segmented the company's main fabric by choosing unwisely and forgetting to practice safe zoning we'll choose to buy them a drink or two. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: generating a Linux WWN?
Matthew Jacob wrote: A much better choice is to get real stamped serial number WWNs. I also hold with some of the other folks on this discussion that some of this is policy that the admin should be allowed to choose. After they've segmented the company's main fabric by choosing unwisely and forgetting to practice safe zoning we'll choose to buy them a drink or two. hehe :) Let's not forget, too, that this entire thread is talking about the 1% case. The common case everybody agrees on -- the manufacturer should provide a unique WWN for each board etc. That's the 99% case. And just like ethernet NICs, the system works as intended /most of the time/. Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: generating a Linux WWN?
On Wed, Oct 03, 2007 at 08:23:14PM -0700, Matthew Jacob wrote: For smaller bit spaces like 64 bit WWNs, you cannot, as you correctly point out, generate reliably unique numbers all by youself. The closest you could probably come is using a type 5 WWN with a known single OUI and then use seconds since January 1 2007 as a serial number in the 36 bit VID space that gives you about 8 years before it wraps- the likely collision rate here would be pretty low. Unless you generate more than one WWN per second. We could enforce that by have an msleep(1000) in the WWN generator function ... which might discourage people from using it except when they really had to ;-) Of course, if you turn on two computers in the same zone at the same time, you're still screwed. -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
