Re: [PATCH 1/5] add dma_max_segment_size option to scsi_host_template
FUJITA Tomonori wrote:
You are right. scsi_debug's pseudo-bus works.
But probabaly, scsi_debug doesn't need to call
blk_queue_max_segment_size now.
Either way works for me. :)
Maybe dev_set_max_seg() is a better name, if people get really picky (I
don't care).
How about dma_set_max_seg_size()?
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index a417a6f..7adadfb 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1554,6 +1554,7 @@ struct request_queue *__scsi_alloc_queue(struct Scsi_Host
*shost,
request_fn_proc *request_fn)
{
struct request_queue *q;
+ struct device *dev = shost-shost_gendev.parent;
q = blk_init_queue(request_fn, NULL);
if (!q)
@@ -1565,6 +1566,9 @@ struct request_queue *__scsi_alloc_queue(struct Scsi_Host
*shost,
blk_queue_bounce_limit(q, scsi_calculate_bounce_limit(shost));
blk_queue_segment_boundary(q, shost-dma_boundary);
+ if (dev-max_segment_size)
+ blk_queue_max_segment_size(q, dev-max_segment_size);
+
if (!shost-use_clustering)
clear_bit(QUEUE_FLAG_CLUSTER, q-queue_flags);
return q;
diff --git a/include/linux/device.h b/include/linux/device.h
index 3a38d1f..8046b60 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -443,6 +443,13 @@ struct device {
struct dma_coherent_mem *dma_mem; /* internal for coherent mem
override */
+
+ /*
+* a low level driver may set these to teach IOMMU code about
+* sg limitations.
+*/
+ unsigned int max_segment_size;
+
/* arch specific additions */
struct dev_archdata archdata;
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 2dc21cb..30404b8 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -31,6 +31,11 @@ static inline int valid_dma_direction(int dma_direction)
(dma_direction == DMA_FROM_DEVICE));
}
+static inline void dma_set_max_seg_size(struct device *dev, unsigned int size)
+{
+ dev-max_segment_size = size;
+}
+
Definitely moving in the right direction, IMO. I would suggest a few
minor changes to dma_set_max_seg_size(), to permit platforms to override
the default behavior, and to get people into the habit of checking the
return value (since it might matter in the future):
1) surround with #ifndef ARCH_HAS_DMA_MAX_SEG
2) change return value to 'int'
3) unconditionally return zero, for now.
Otherwise, approach and code look good to me.
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: /dev/sda with 8 byte offset
Al Viro wrote: On Wed, Sep 26, 2007 at 10:55:11PM +0200, Stefan Richter wrote: Strange. I haven't heard of this before. From which vendor and model is the device, and do you know which chip is on its IDE bridge board? I've seen it, all right. 8 bytes stuck in FIFO, pl3507 IDE bridge, and judging by google search that turd is b0rken regardless of the OS (along the lines of works under Windows if you power-cycle it once in about half an hour). Suggested fix: use as a barf-bag; the authors of that thing certainly had done that. Sounds plausible. I wasn't aware of the particular 8-byte-garbage symptom (or heard of it and forgot it). Some people (regardless if Windows, OS X, or Linux users) were able to make their PL3507 work with new firmware: http://wiki.linux1394.org/FirmwareDownload Very old revisions of the chip don't support firmware upload. And some boards with newer revisions apparently prevent firmware upload with a resistor: http://club.cdfreaks.com/showthread.php?p=957178 -- Stefan Richter -=-=-=== =--= ==-== http://arcgraph.de/sr/ - 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: /dev/sda with 8 byte offset
On Thu, Sep 27, 2007 at 08:45:09AM +0200, Stefan Richter wrote: Al Viro wrote: On Wed, Sep 26, 2007 at 10:55:11PM +0200, Stefan Richter wrote: Strange. I haven't heard of this before. From which vendor and model is the device, and do you know which chip is on its IDE bridge board? I've seen it, all right. 8 bytes stuck in FIFO, pl3507 IDE bridge, and judging by google search that turd is b0rken regardless of the OS (along the lines of works under Windows if you power-cycle it once in about half an hour). Suggested fix: use as a barf-bag; the authors of that thing certainly had done that. Sounds plausible. I wasn't aware of the particular 8-byte-garbage symptom (or heard of it and forgot it). IIRC, it can be triggered by the second INQUIRY during the same firewire session (i.e. device survives only one INQUIRY after login and using e.g. scsiinfo -i afterwards triggers that behaviour). Can't verify that, since the hardware in question had been met its end (after a week spent debugging that mess). It was of the can't upgrade the firmware variety and frankly, it's easier to spend $20 on a working enclosure than to waste time on that dreck. - 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 v3 2/2][BNX2]: Add iSCSI support to BNX2 devices.
CC'ed Jens, James, and linux-scsi. On Thu, 27 Sep 2007 03:31:55 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: FUJITA Tomonori wrote: Yeah, we could nicely handle lld's restrictions (especially with stacking devices). But iommu code needs only max_segment_size and seg_boundary_mask, right? If so, the first simple approach to add two values to device structure is not so bad, I think. (replying to slightly older email in the thread) (added benh, since we've discussed this issue in the past) dumb question, what happened to seg_boundary_mask? I'll work on it too after finishing max_seg_size. If you look at drivers/ata/libata-core.c:ata_fill_sg(), you will note that we split s/g segments after DMA-mapping. Looking at libata LLDD's, you will also note judicious use of ATA_DMA_BOUNDARY (0x). I know the workaround since I fixed libata's sg chaining patch. It was drilled into my head by James and benh that I cannot rely on the DMA boundary + block/scsi + dma_map_sg() to ensure that my S/G segments never cross a 64K boundary, a legacy IDE requirement. Thus the additional code in ata_fill_sg() to split S/G segments straddling 64K, in addition to setting dma boundary to 0x. I think that the block layer can handle both max_segment_size and seg_boundary_mask properly (and SCSI-ml just uses the block layer). So if we fix iommu, then we can remove a workaround to fix sg lists in llds. A key problem I was hoping would be solved with your work here was the elimination of that post dma_map_sg() split. Yeah, that's my goal too. If I understood James and Ben correctly, one of the key problems was always in communicating libata's segment boundary needs to the IOMMU layers? 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 v3 2/2][BNX2]: Add iSCSI support to BNX2 devices.
FUJITA Tomonori wrote: CC'ed Jens, James, and linux-scsi. On Thu, 27 Sep 2007 03:31:55 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: FUJITA Tomonori wrote: Yeah, we could nicely handle lld's restrictions (especially with stacking devices). But iommu code needs only max_segment_size and seg_boundary_mask, right? If so, the first simple approach to add two values to device structure is not so bad, I think. (replying to slightly older email in the thread) (added benh, since we've discussed this issue in the past) dumb question, what happened to seg_boundary_mask? I'll work on it too after finishing max_seg_size. If you look at drivers/ata/libata-core.c:ata_fill_sg(), you will note that we split s/g segments after DMA-mapping. Looking at libata LLDD's, you will also note judicious use of ATA_DMA_BOUNDARY (0x). I know the workaround since I fixed libata's sg chaining patch. It was drilled into my head by James and benh that I cannot rely on the DMA boundary + block/scsi + dma_map_sg() to ensure that my S/G segments never cross a 64K boundary, a legacy IDE requirement. Thus the additional code in ata_fill_sg() to split S/G segments straddling 64K, in addition to setting dma boundary to 0x. I think that the block layer can handle both max_segment_size and seg_boundary_mask properly (and SCSI-ml just uses the block layer). So if we fix iommu, then we can remove a workaround to fix sg lists in llds. A key problem I was hoping would be solved with your work here was the elimination of that post dma_map_sg() split. Yeah, that's my goal too. Great :) Well, I'm generally happy with your max-seg-size stuff (sans the minor nits I pointed out in another email). Thanks for pursuing 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 v3 2/2][BNX2]: Add iSCSI support to BNX2 devices.
CC'ed Jens, James, and linux-scsi again. On Thu, 27 Sep 2007 04:22:15 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: Benjamin Herrenschmidt wrote: On Thu, 2007-09-27 at 03:49 -0400, Jeff Garzik wrote: Benjamin Herrenschmidt wrote: On Thu, 2007-09-27 at 03:31 -0400, Jeff Garzik wrote: A key problem I was hoping would be solved with your work here was the elimination of that post dma_map_sg() split. If I understood James and Ben correctly, one of the key problems was always in communicating libata's segment boundary needs to the IOMMU layers? Yup. If we can put some constraint in struct device that the dma mapping code can then look at ... we also need to ensure that what's passed in for DMA'ing already matches those constraints as well since no-iommu platforms will basically just keep the dma table as-is. That's a good point... no-iommu platforms would need to be updated to do the split for me. I suppose we can steal that code from swiotlb or somewhere. Doing the split means being able to grow the sglist... which the dma_* calls can't do at least not in their current form. IMO one straightforward approach is for the struct scatterlist owner to provide a table large enough to accomodate the possible splits (perhaps along with communicate that table's max size to the IOMMU/dma layers). As I said in another mail, the block layer and scsi-ml work properly, I think. So there is no need to split sg lists for no-iommu platforms. We need to fix only iommu code merge sglists (already done) for the segment size restriction but we need to fix all iommu code and swiotlb for the segment boundary restriction. Splitting sg list might be useful for the case that iommu can't find a proper boundary memory area. But I think that it rarely happens (and there are few llds has the boundary restriction). - 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
generating a Linux WWN?
Is there an accepted way to generate a SAS address, when the adapter does not supply one (NVRAM invalid or missing, etc.)? Unless somebody complains, I was just planning to use get_random_bytes(). But maybe Linux has an IEEE id we can use, to make the practice a bit more legitimate and avoid stomping on others? Or an IEEE id specifically designed for generated-address purposes? 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: [linux-usb-devel] question on flushing buffers and spinning down disk
Am Dienstag 25 September 2007 schrieb Alan Stern:
Getting all this to work will be tricky, because sd is a block device
driven by requests issued through the block layer in atomic context,
whereas suspend and resume require a process context. Probably the
SCSI core would have to get involved in managing the synchronization.
Well,
here's a patch that seems to do what needs to be done to make it work.
Regards
Oliver
--- a/drivers/usb/storage/usb.c 2007-09-27 13:33:31.0 +0200
+++ b/drivers/usb/storage/usb.c 2007-09-27 13:30:21.0 +0200
@@ -182,33 +182,100 @@ static struct us_unusual_dev us_unusual_
static int storage_suspend(struct usb_interface *iface, pm_message_t message)
{
+ struct device *child;
struct us_data *us = usb_get_intfdata(iface);
+ struct Scsi_Host *host = us_to_host(us);
+ struct scsi_device *sdev, *sdev2 = NULL;
+ int err = 0;
+
+ /* In case of autosuspend we need to do extra work to flush
+* buffers and spin down disks. */
+ if (us-pusb_dev-auto_pm) {
+ US_DEBUGP(Autosuspend code path.\n);
+ /* block all devices against block and user space io */
+ shost_for_each_device(sdev, host) {
+ US_DEBUGP(Quiescing device.\n);
+ err = scsi_device_quiesce(sdev);
+ US_DEBUGP(Quiesced device with result %d.\n, err);
+ if (err 0) {
+ sdev2 = sdev;
+ err = -EIO;
+ scsi_device_put(sdev);
+ goto err_unblock;
+ }
+ child = sdev-sdev_gendev;
+ if (!child-driver || !child-driver-suspend)
+ continue;
+ US_DEBUGP(About to suspend disk.\n);
+ /* flush the buffers and spin down */
+ err = (child-driver-suspend)(child, message);
+ if (err 0) {
+ US_DEBUGP(Could not suspend disk.\n);
+ sdev2 = sdev;
+ shost_for_each_device(sdev, host) {
+ if (sdev == sdev2) {
+ scsi_device_put(sdev);
+ break;
+ }
+ child = sdev-sdev_gendev;
+ if (!child-driver ||
!child-driver-resume)
+ continue;
+ (child-driver-resume)(child);
+ }
+ err = -EIO;
+ sdev2 = NULL;
+ scsi_device_put(sdev);
+ goto err_unblock;
+ }
+ }
+ }
+
+ US_DEBUGP(%s\n, __FUNCTION__);
/* Wait until no command is running */
mutex_lock(us-dev_mutex);
- US_DEBUGP(%s\n, __FUNCTION__);
if (us-suspend_resume_hook)
(us-suspend_resume_hook)(us, US_SUSPEND);
- /* When runtime PM is working, we'll set a flag to indicate
-* whether we should autoresume when a SCSI request arrives. */
-
mutex_unlock(us-dev_mutex);
- return 0;
+
+ /* In case of autosuspend device must be unblocked again */
+ if (us-pusb_dev-auto_pm) {
+err_unblock:
+ shost_for_each_device(sdev, host) {
+ if (sdev == sdev2) {
+ scsi_device_put(sdev);
+ break;
+ }
+ scsi_device_resume(sdev);
+ }
+ }
+ return err;
}
static int storage_resume(struct usb_interface *iface)
{
struct us_data *us = usb_get_intfdata(iface);
+ struct Scsi_Host *host;
+ struct scsi_device *sdev;
+ struct device *child;
- mutex_lock(us-dev_mutex);
+ if (us-pusb_dev-auto_pm) {
+ host = us_to_host(us);
+ shost_for_each_device(sdev, host) {
+ child = sdev-sdev_gendev;
+ if (!child-driver || !child-driver-resume)
+ continue;
+ (child-driver-resume)(child);
+ }
+ }
US_DEBUGP(%s\n, __FUNCTION__);
+
if (us-suspend_resume_hook)
(us-suspend_resume_hook)(us, US_RESUME);
- mutex_unlock(us-dev_mutex);
return 0;
}
@@ -306,6 +373,7 @@ static int usb_stor_control_thread(void
{
struct us_data *us = (struct us_data *)__us;
struct Scsi_Host *host = us_to_host(us);
+ int autopm_rc;
for(;;) {
Re: generating a Linux WWN?
Uh, although this may work very well for small constrained configs, as one who debugs larger environments (and things always grow or get connected in ways you don't expect), depending on a random number for uniqueness makes me very unsettled. Debugging that small-percentage potential, when/if it does occur can be an absolute nightmare with all kinds of weird behavior. Rarely will you solve it from the context of a single server. There are lots of ways to cheat, but I believe they all have to be based on some small part that is guaranteed to be unique (like the IEEE id's). -- james s Jeff Garzik wrote: Is there an accepted way to generate a SAS address, when the adapter does not supply one (NVRAM invalid or missing, etc.)? Unless somebody complains, I was just planning to use get_random_bytes(). But maybe Linux has an IEEE id we can use, to make the practice a bit more legitimate and avoid stomping on others? Or an IEEE id specifically designed for generated-address purposes? 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: generating a Linux WWN?
James Smart wrote: Uh, although this may work very well for small constrained configs, as one who debugs larger environments (and things always grow or get connected in ways you don't expect), depending on a random number for uniqueness makes me very unsettled. Debugging that small-percentage potential, when/if it does occur can be an absolute nightmare with all kinds of weird behavior. Rarely will you solve it from the context of a single server. There are lots of ways to cheat, but I believe they all have to be based on some small part that is guaranteed to be unique (like the IEEE id's). That's the ideal world, sure :) But the reality is, just like with ethernet MAC addresses, you don't always have one when you supposed to have one. There are obvious limitations and problems arising from a generated WWN -- particularly for an HBA, where serial numbers and other unique identifiers are scarce. But that doesn't wish the missing-WWN problem away. Decades of networking experience have taught us a few things :) As an aside, we also need a way to override the HBA's WWN, just like we do with ethernet MAC address. 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?
Unfortunately, it looks like IEEE doesn't have any OID's registered for Linux or other reserved areas (http://standards.ieee.org/regauth/oui/oui.txt). However, it does look like they go in order... so maybe if you used an OID of 0xFF you could at least guarantee that you didn't conflict with any company's SAS WWNs. Patrick Boyd James Smart wrote: Uh, although this may work very well for small constrained configs, as one who debugs larger environments (and things always grow or get connected in ways you don't expect), depending on a random number for uniqueness makes me very unsettled. Debugging that small-percentage potential, when/if it does occur can be an absolute nightmare with all kinds of weird behavior. Rarely will you solve it from the context of a single server. There are lots of ways to cheat, but I believe they all have to be based on some small part that is guaranteed to be unique (like the IEEE id's). -- james s Jeff Garzik wrote: Is there an accepted way to generate a SAS address, when the adapter does not supply one (NVRAM invalid or missing, etc.)? Unless somebody complains, I was just planning to use get_random_bytes(). But maybe Linux has an IEEE id we can use, to make the practice a bit more legitimate and avoid stomping on others? Or an IEEE id specifically designed for generated-address purposes? 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 - 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: James Smart wrote: Uh, although this may work very well for small constrained configs, as one who debugs larger environments (and things always grow or get connected in ways you don't expect), depending on a random number for uniqueness makes me very unsettled. Debugging that small-percentage potential, when/if it does occur can be an absolute nightmare with all kinds of weird behavior. Rarely will you solve it from the context of a single server. There are lots of ways to cheat, but I believe they all have to be based on some small part that is guaranteed to be unique (like the IEEE id's). That's the ideal world, sure :) But the reality is, just like with ethernet MAC addresses, you don't always have one when you supposed to have one. I'm curious about the problem you're trying to solve. Generally a missing WWN, as having a unique WWN should be a product requirement, is an indicator of a problem. Shouldn't the proper solution be to have the card repaired? Arbitrarily assigning a WWN could mask or introduce other problems, in particular with regard to storage connectivity. There are obvious limitations and problems arising from a generated WWN -- particularly for an HBA, where serial numbers and other unique identifiers are scarce. But that doesn't wish the missing-WWN problem away. Decades of networking experience have taught us a few things :) As an aside, we also need a way to override the HBA's WWN, just like we do with ethernet MAC address. We do? Perhaps if it's corrupt and you know the correct value. But, in that case shouldn't the card be replaced? When would you need to override the default WWN? Linux: it's not just for desktops anymore. :) 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 4/5] qla2xxx: add target mode support
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. If you have, could you share the details of the layout of the environment that you have had used for the feature verification? Also, it would be great if shared with me for those specific test cases that need to be in place. I will try to add more cases on top of it if there are. Thank you, Seokmann - 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 Wilcox wrote: On Thu, Sep 27, 2007 at 09:16:13AM -0500, [EMAIL PROTECTED] wrote: Unfortunately, it looks like IEEE doesn't have any OID's registered for Linux or other reserved areas (http://standards.ieee.org/regauth/oui/oui.txt). However, it does look like they go in order... so maybe if you used an OID of 0xFF you could at least guarantee that you didn't conflict with any company's SAS WWNs. It's something that happens frequently enough that we should come up with a proper way of handling this. I heard a story of someone at HP taking an old computer, reading the MAC address from the motherboard, then snapping the board in half. I suppose if you're going to use a MAC address from a 10Mbit ethernet card for a SAS WWN, there's no chance of conflict, but still ... 3com might choose to do the same thing, and then we're in trouble. Record the WWN of your SAS / FC port so that if/when it goes missing you can put it back? Have spares on site? I don't have a good solution for WWN assignment. Even if we get a 24-bit OID assignment for 'software use' or something, how do we control the use withi the SAN to be sure we get no overlapping WWNs? Your point here is that overriding a WWN assignment is asking for trouble. Mike - 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: Matthew Wilcox wrote: On Thu, Sep 27, 2007 at 09:16:13AM -0500, [EMAIL PROTECTED] wrote: Unfortunately, it looks like IEEE doesn't have any OID's registered for Linux or other reserved areas (http://standards.ieee.org/regauth/oui/oui.txt). However, it does look like they go in order... so maybe if you used an OID of 0xFF you could at least guarantee that you didn't conflict with any company's SAS WWNs. It's something that happens frequently enough that we should come up with a proper way of handling this. I heard a story of someone at HP taking an old computer, reading the MAC address from the motherboard, then snapping the board in half. I suppose if you're going to use a MAC address from a 10Mbit ethernet card for a SAS WWN, there's no chance of conflict, but still ... 3com might choose to do the same thing, and then we're in trouble. Record the WWN of your SAS / FC port so that if/when it goes missing you can put it back? Have spares on site? Our vendor recommends fixing the board, not applying a band-aid. A random WWN will potentially not work as the board firmware does some level of sanity checking. YMMV. Mike I don't have a good solution for WWN assignment. Even if we get a 24-bit OID assignment for 'software use' or something, how do we control the use withi the SAN to be sure we get no overlapping WWNs? Your point here is that overriding a WWN assignment is asking for trouble. Mike - 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: generating a Linux WWN?
Michael Reed wrote: Jeff Garzik wrote: James Smart wrote: Uh, although this may work very well for small constrained configs, as one who debugs larger environments (and things always grow or get connected in ways you don't expect), depending on a random number for uniqueness makes me very unsettled. Debugging that small-percentage potential, when/if it does occur can be an absolute nightmare with all kinds of weird behavior. Rarely will you solve it from the context of a single server. There are lots of ways to cheat, but I believe they all have to be based on some small part that is guaranteed to be unique (like the IEEE id's). That's the ideal world, sure :) But the reality is, just like with ethernet MAC addresses, you don't always have one when you supposed to have one. I'm curious about the problem you're trying to solve. Generally a missing WWN, as having a unique WWN should be a product requirement, is an indicator of a problem. Shouldn't the proper solution be to have the card repaired? Arbitrarily assigning a WWN could mask or introduce other problems, in particular with regard to storage connectivity. I have come across two types of problems: a) the scsi_debug driver looks like one or more logical units behind one or more dual ported SAS devices. All generated SAS address (for target ports, target devices and lus) should be distinct and preferably world wide unique. [My scsi_ses driver has a similar problem.] b) SAS HBAs that can run in target mode don't have enough unique SAS addresses allocated. A SAS initiator (the HBA's normal mode) only needs a couple a SAS addresses (e.g. 3: one for the 4 internal phys, another for the 4 external phys and 1 for the SAS initiator _device_ (but I have never seen that done properly)). When you turn the SAS HBA around as a target (or initiator/target for bonus points) then each logical unit connected to or simulated by the SAS target needs a unique SAS address. Years ago I asked for linux to get a IEEE OID. In the absence of that perhaps we should use 0xff. FreeBSD, OpenBSD etc face a similar problem. Doug Gilbert There are obvious limitations and problems arising from a generated WWN -- particularly for an HBA, where serial numbers and other unique identifiers are scarce. But that doesn't wish the missing-WWN problem away. Decades of networking experience have taught us a few things :) As an aside, we also need a way to override the HBA's WWN, just like we do with ethernet MAC address. We do? Perhaps if it's corrupt and you know the correct value. But, in that case shouldn't the card be replaced? When would you need to override the default WWN? Linux: it's not just for desktops anymore. :) 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
Re: [linux-usb-devel] question on flushing buffers and spinning down disk
On Thu, 27 Sep 2007, Oliver Neukum wrote: Am Dienstag 25 September 2007 schrieb Alan Stern: Getting all this to work will be tricky, because sd is a block device driven by requests issued through the block layer in atomic context, whereas suspend and resume require a process context. Probably the SCSI core would have to get involved in managing the synchronization. Well, here's a patch that seems to do what needs to be done to make it work. Oliver, I'm surprised at you! This patch is a big hack, not to mention a layering violation and an inversion of the proper calling sequence. Alan Stern - 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] x86-64: pci-gart iommu sg chaining zeroes wrong sg.
This patch is for Jens' block tree (sg chaining branch). I don't have the hardware but this looks like a bug. --- From: FUJITA Tomonori [EMAIL PROTECTED] Subject: [PATCH] x86-64: pci-gart iommu sg chaining zeroes a wrong sg's dma_length Needs to zero the end of the list. Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] --- arch/x86_64/kernel/pci-gart.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/x86_64/kernel/pci-gart.c b/arch/x86_64/kernel/pci-gart.c index 27b7db4..a4151a7 100644 --- a/arch/x86_64/kernel/pci-gart.c +++ b/arch/x86_64/kernel/pci-gart.c @@ -425,9 +425,10 @@ int gart_map_sg(struct device *dev, struct scatterlist *sg, int nents, int dir) if (dma_map_cont(start_sg, i - start, sgmap, pages, need) 0) goto error; out++; + sgmap = sg_next(sgmap); flush_gart(); if (out nents) - ps-dma_length = 0; + sgmap-dma_length = 0; return out; error: -- 1.5.2.4 - 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] x86-64: pci-gart iommu sg chaining zeroes wrong sg.
On Fri, 28 Sep 2007 01:38:27 +0900
FUJITA Tomonori [EMAIL PROTECTED] wrote:
This patch is for Jens' block tree (sg chaining branch).
I don't have the hardware but this looks like a bug.
---
From: FUJITA Tomonori [EMAIL PROTECTED]
Subject: [PATCH] x86-64: pci-gart iommu sg chaining zeroes a wrong sg's
dma_length
Needs to zero the end of the list.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
arch/x86_64/kernel/pci-gart.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/x86_64/kernel/pci-gart.c b/arch/x86_64/kernel/pci-gart.c
index 27b7db4..a4151a7 100644
--- a/arch/x86_64/kernel/pci-gart.c
+++ b/arch/x86_64/kernel/pci-gart.c
@@ -425,9 +425,10 @@ int gart_map_sg(struct device *dev, struct scatterlist
*sg, int nents, int dir)
if (dma_map_cont(start_sg, i - start, sgmap, pages, need) 0)
goto error;
out++;
+ sgmap = sg_next(sgmap);
flush_gart();
if (out nents)
- ps-dma_length = 0;
+ sgmap-dma_length = 0;
return out;
Sorry, it should be:
diff --git a/arch/x86_64/kernel/pci-gart.c b/arch/x86_64/kernel/pci-gart.c
index 27b7db4..cfcc84e 100644
--- a/arch/x86_64/kernel/pci-gart.c
+++ b/arch/x86_64/kernel/pci-gart.c
@@ -426,8 +426,10 @@ int gart_map_sg(struct device *dev, struct scatterlist
*sg, int nents, int dir)
goto error;
out++;
flush_gart();
- if (out nents)
- ps-dma_length = 0;
+ if (out nents) {
+ sgmap = sg_next(sgmap);
+ sgmap-dma_length = 0;
+ }
return out;
error:
-
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: [linux-usb-devel] question on flushing buffers and spinning down disk
Am Donnerstag 27 September 2007 schrieb Alan Stern: On Thu, 27 Sep 2007, Oliver Neukum wrote: Am Dienstag 25 September 2007 schrieb Alan Stern: Getting all this to work will be tricky, because sd is a block device driven by requests issued through the block layer in atomic context, whereas suspend and resume require a process context. Probably the SCSI core would have to get involved in managing the synchronization. Well, here's a patch that seems to do what needs to be done to make it work. Oliver, I'm surprised at you! This patch is a big hack, not to mention a layering violation and an inversion of the proper calling sequence. Well, 1. autosuspend should not be specific to USB 2. I like to view the generic SCSI code as a library 3. The low level drivers will have to decide whether to suspend devices, as the generic code doesn't know whether the bus is shared. Regards Oliver - 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: [linux-usb-devel] question on flushing buffers and spinning down disk
On Thu, 27 Sep 2007, Oliver Neukum wrote: Oliver, I'm surprised at you! This patch is a big hack, not to mention a layering violation and an inversion of the proper calling sequence. Well, 1. autosuspend should not be specific to USB Correct. Which means support for it should be added to the SCSI drivers. SCSI autosuspend shouldn't be kluged into usb-storage in a way that basically ignores what the SCSI layer is doing. 2. I like to view the generic SCSI code as a library That viewpoint might work out okay in some cases, but I don't think it's tenable when dealing with high-level drivers like sd and sr. 3. The low level drivers will have to decide whether to suspend devices, as the generic code doesn't know whether the bus is shared. I'm having trouble understanding this; it's a bit ambiguous. Does devices mean SCSI devices, host adapter devices, or both? Does generic code refer to the SCSI core, the high-level SCSI drivers, or something else? When you say the bus is shared, do you mean there are multiple SCSI devices attached to it or do you mean something else? (I assume you mean something else, as the SCSI core certainly does know when multiple SCSI devices are attached to a SCSI bus.) In any case, that's not how I would put it. The SCSI core and high-level drivers will have to decide when they are not using SCSI devices and the devices can be suspended. When all the devices the SCSI core knows about are suspended, it should tell the LLD. Then the LLD can suspend the bus and the host adapter, whatever is appropriate, based on its own private knowledge. Alan Stern - 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: [linux-usb-devel] question on flushing buffers and spinning down disk
Am Donnerstag 27 September 2007 schrieb Alan Stern: On Thu, 27 Sep 2007, Oliver Neukum wrote: Oliver, I'm surprised at you! This patch is a big hack, not to mention a layering violation and an inversion of the proper calling sequence. Well, 1. autosuspend should not be specific to USB Correct. Which means support for it should be added to the SCSI drivers. SCSI autosuspend shouldn't be kluged into usb-storage in a way that basically ignores what the SCSI layer is doing. It isn't. The decision to autosuspend is based on activity on the bus. Now you might argue that the decision to do an autosuspend should always propagate upwards from the lowest level of the device tree. Then I ask why? 2. I like to view the generic SCSI code as a library That viewpoint might work out okay in some cases, but I don't think it's tenable when dealing with high-level drivers like sd and sr. sg worries me. 3. The low level drivers will have to decide whether to suspend devices, as the generic code doesn't know whether the bus is shared. I'm having trouble understanding this; it's a bit ambiguous. Does devices mean SCSI devices, host adapter devices, or both? Does SCSI devices generic code refer to the SCSI core, the high-level SCSI drivers, or something else? When you say the bus is shared, do you mean there are multiple SCSI devices attached to it or do you mean something else? No multiple hosts. Think Firewire or FibreChannel. We certainly cannot spin down a Firewire disk some other host is using just because we are done with it. (I assume you mean something else, as the SCSI core certainly does know when multiple SCSI devices are attached to a SCSI bus.) In any case, that's not how I would put it. The SCSI core and high-level drivers will have to decide when they are not using SCSI devices and the devices can be suspended. When all the devices the Err, why? After all, there's a central instance in userspace that decides that the whole system isn't used right now. I see no reason to not use this model for parts of the device tree. Regards Oliver - 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: /dev/sda with 8 byte offset
On Wed, 26 Sep 2007, Stefan Richter wrote: (Adding Cc: linux-scsi) Stefan Rutzinger wrote: I experience a very weird offset in the data from my FW disk. It worked well last time i used it, which is about half a year ago. Unfortunately i can't tell what exactly changed in the meanwhile, i continued updating debian testing an think (but am not sure) changed the kernel. However, this seems to be a real bug which should not be there anyway. So, the disk is a USB / firewire disk. It still works fine with USB in linux and with USB + firewire in Win XP. So the hardware is certainly still fine. But with firewire and linux, there is this problem: It't still detected with correct disk geometry and /dev/sda and /dev/sda1 are recognised. But fdisk -l /dev/sda fails: Disk /dev/sda doesn't contain a valid partition table I dd'ed the mbr to a file, once when connected by USB and once when connected to Firewire and found out with cmp: The data in /dev/sda and /dev/sda1 are shifted by an offset of 8 byte in the firewire case. I.e. there are some additional 8 byte at the beginning of /dev/sda and /dev/sda1 which should not be there. Have a look at the cmp output below. Of course fdisk fails then. Strange. I haven't heard of this before. From which vendor and model is the device, and do you know which chip is on its IDE bridge board? Did you ever install new firmware on the device? Who can help out? Here' some debugging data: I tried debian pre-compiled kernel 2.6.15-1-686-smp and 2.6.21-2-686. stefaniello:~# cmp -bln16 usb-sda1 ieee-sda1 1 353 M-k 40 - 2 130 X123 S | 3 220 M-^P 131 Y | 4 115 M123 S | 5 123 S 0 ^@ | 6 127 W 0 ^@ | 7 111 I125 U | 8 116 N252 M-*| 9 64 4353 M-k -- - 8 byte offset ! 10 56 .130 X 11 61 1220 M-^P 12 0 ^@ 115 M 13 2 ^B 123 S 14 100 @127 W 15 46 111 I 16 0 ^@ 116 N USB connected: stefaniello:~# tail /var/log/messages Sep 20 19:30:47 stefaniello kernel: usb 1-1: new full speed USB device using uhci_hcd and address 2 Sep 20 19:30:47 stefaniello kernel: scsi0 : SCSI emulation for USB Mass Storage devices Sep 20 19:30:52 stefaniello kernel: Vendor: WDC WD20 Model: 00JB-00GVA0 Rev: 08.0 Sep 20 19:30:52 stefaniello kernel: Type: Direct-Access ANSI SCSI revision: 00 Sep 20 19:30:52 stefaniello kernel: SCSI device sda: 390721969 512-byte hdwr sectors (200050 MB) Sep 20 19:30:52 stefaniello kernel: SCSI device sda: 390721969 512-byte hdwr sectors (200050 MB) Sep 20 19:30:52 stefaniello kernel: sda: sda1 Sep 20 19:30:52 stefaniello kernel: sd 0:0:0:0: Attached scsi disk sda Sep 20 19:30:53 stefaniello kernel: sda: Current: sense key: No Sense Sep 20 19:30:53 stefaniello kernel: Additional sense: No additional sense information stefaniello:~# fdisk -l /dev/sda Disk /dev/sda: 200.0 GB, 200049648128 bytes 255 heads, 63 sectors/track, 24321 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 1 24321 195358401b W95 FAT32 ieee1394 connected: stefaniello:~# tail -f /var/log/messages Sep 20 19:42:04 stefaniello kernel: scsi1 : SCSI emulation for IEEE-1394 SBP-2 Devices (This was obviously obtained from Debian's 2.6.15.) Sep 20 19:42:05 stefaniello kernel: ieee1394: sbp2: Logged into SBP-2 device Sep 20 19:42:05 stefaniello kernel: Vendor: WDC WD20 Model: 00JB-00GVA0 Rev: Sep 20 19:42:05 stefaniello kernel: Type: Direct-Access-RBC ANSI SCSI revision: 04 Sep 20 19:42:05 stefaniello kernel: SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB) Sep 20 19:42:05 stefaniello kernel: SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB) Sep 20 19:42:05 stefaniello kernel: sda: sda1 Sep 20 19:42:05 stefaniello kernel: sd 1:0:0:0: Attached scsi disk sda stefaniello:~# fdisk -l /dev/sda Disk /dev/sda: 200.0 GB, 200049647616 bytes 255 heads, 63 sectors/track, 24321 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk /dev/sda doesn't contain a valid partition table I don't know what could cause this. The sbp2 driver did a lot of SCSI command conversions between the RBC and SBC command sets in older kernels, and this was gradually pulled out of sbp2 because the sd driver already handled RBC properly at some point. In Linux 2.6.15, sbp2 had still all this conversion code but it was AFAIK already deadwood. However I don't know if there could really be differences in how very old kernels sent SCSI commands which could cause the device to return data with an offset. Perhaps the problem is not in what data the device returns when sd reads from it, but in where the data is written into buffers. I.e. if going through sbp2, the data might be written 8 bytes behind the actual start of the data buffer. I will check in the SBP-2 spec if there is anything that could be mistaken about the buffer address. By the way, in
Re: [linux-usb-devel] question on flushing buffers and spinning down disk
On Thu, 27 Sep 2007, Oliver Neukum wrote: 1. autosuspend should not be specific to USB Correct. Which means support for it should be added to the SCSI drivers. SCSI autosuspend shouldn't be kluged into usb-storage in a way that basically ignores what the SCSI layer is doing. It isn't. The decision to autosuspend is based on activity on the bus. Now you might argue that the decision to do an autosuspend should always propagate upwards from the lowest level of the device tree. Then I ask why? Because that's how I have always thought of it... :-) You're right; there's no showstopping reason particular subsystems like SCSI can't use a different approach. However bus activity alone isn't a sufficient criterion. For example, suppose somebody sends a PLAY AUDIO command to a SCSI cdrom drive. There won't be any bus activity while the music is playing, but the device will be active and so it shouldn't be suspended. Thus the sr driver would want to fail an autosuspend call. Anyway, if we do end up going this route then there should be a routine added to the SCSI core which would call the suspend methods for all the attached devices. This doesn't belong in usb-storage (and even worse, it shouldn't be duplicated in all the other low-level drivers); rather, usb-storage should simply be able to call the new routine. Have you thought about how autoresume would fit into this picture? I don't think you can rely on usb-storage telling the SCSI core to resume devices when it gets handed a command, because the commands to spin-up the drives would have to be transmitted first. (The sample patch you posted will deadlock: The other command can't begin until the spin-up command completes, and the spin-up command won't get sent to usb-storage until the original command completes.) In other words, autoresume must be handled at the level of the SCSI core. What happens if you want to autosuspend some of the devices on a SCSI bus but not all of them? Obviously usb-storage wouldn't be able to handle that, since all it knows about is overall bus activity. 2. I like to view the generic SCSI code as a library That viewpoint might work out okay in some cases, but I don't think it's tenable when dealing with high-level drivers like sd and sr. sg worries me. Let's not worry about it for now. 3. The low level drivers will have to decide whether to suspend devices, as the generic code doesn't know whether the bus is shared. I'm having trouble understanding this; it's a bit ambiguous. Does devices mean SCSI devices, host adapter devices, or both? Does SCSI devices generic code refer to the SCSI core, the high-level SCSI drivers, or something else? When you say the bus is shared, do you mean there are multiple SCSI devices attached to it or do you mean something else? No multiple hosts. Think Firewire or FibreChannel. We certainly cannot spin down a Firewire disk some other host is using just because we are done with it. But what if no other hosts are attached? Would you still want to avoid spinning down the disk? Would the disk somehow have to become responsible for spinning itself down? Anyway, this isn't usb-storage's problem. (For that matter, do the Firewire or FibreChannel drivers know when other hosts are sharing the bus?) In any case, that's not how I would put it. The SCSI core and high-level drivers will have to decide when they are not using SCSI devices and the devices can be suspended. When all the devices the Err, why? After all, there's a central instance in userspace that decides that the whole system isn't used right now. I see no reason to not use this model for parts of the device tree. Autoresume is the major complication. There's also a philosophical objection. Who is in a better position to judge when a device like a SCSI drive should be autosuspended: its own driver (sd) or someone else (usb-storage)? Alan Stern - 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: [linux-usb-devel] question on flushing buffers and spinning down disk
Date: Thu, 27 Sep 2007 16:26:56 -0400 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED]; [EMAIL PROTECTED]; linux-scsi@vger.kernel.org Subject: Re: [linux-usb-devel] question on flushing buffers and spinning down disk On Thu, 27 Sep 2007, Oliver Neukum wrote: 1. autosuspend should not be specific to USB Correct. Which means support for it should be added to the SCSI drivers. SCSI autosuspend shouldn't be kluged into usb-storage in a way that basically ignores what the SCSI layer is doing. It isn't. The decision to autosuspend is based on activity on the bus. Now you might argue that the decision to do an autosuspend should always propagate upwards from the lowest level of the device tree. Then I ask why? Err, why? After all, there's a central instance in userspace that decides that the whole system isn't used right now. I see no reason to not use this model for parts of the device tree. Autoresume is the major complication. There's also a philosophical objection. Who is in a better position to judge when a device like a SCSI drive should be autosuspended: its own driver (sd) or someone else (usb-storage)? Isn't power saving a policy decision? Should it not be left to userspace to control? Doesn't userspace decide to blank the video based on user preferences? Userspace could jump through all sorts of hoops to wait for disks to spin down, etc on the way to powersaving. If we really need the capability to suspend a mouse/keyboard etc after 2-n seconds of no use, shouldn't it be userspace that enables the autosuspend? Has the battery life impact of the various device shutdowns been measured and found useful? Just a bunch of questions, but it seems to me that what is really needed is a mechanism for userspace to do fine grained power control. Regards, Steve _ Connect to the next generation of MSN Messenger http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-ussource=wlmailtagline- 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: [linux-usb-devel] question on flushing buffers and spinning down disk
On Thu, 27 Sep 2007, Steve Calfee wrote: Isn't power saving a policy decision? Whether or not power saving should be implemented and under what conditions it should occur are indeed policy decisions. However the decision to actually power-down a device (because the specified conditions have occurred) is not a policy decision -- it is an action to carry out a policy. Should it not be left to userspace to control? No. You shouldn't expect users to run a program that would notice a particular disk drive hasn't been used in X minutes and then power it down. (Although they could if they wanted to... except that there's no way for userspace to know when the drive was most recently used.) Doesn't userspace decide to blank the video based on user preferences? The X server runs in userspace, yes. However VT console blanking is part of the kernel. So it works both ways. Userspace could jump through all sorts of hoops to wait for disks to spin down, etc on the way to powersaving. I'm not sure what you mean here. What I have described is the way Windows works, for example. You tell the system how long you want it to wait before spinning down an idle drive and it takes care of everything else; you don't have to tell it each time you want the drive spun down. If we really need the capability to suspend a mouse/keyboard etc after 2-n seconds of no use, shouldn't it be userspace that enables the autosuspend? If by enables you mean that userspace tells the system the value of n, then yes. If you mean that userspace waits until the mouse/keyboard has been inactive for n seconds and tells the system to suspend it, then no. (That wouldn't be an autosuspend anyway -- it would be a manual suspend.) Has the battery life impact of the various device shutdowns been measured and found useful? Yes. Just a bunch of questions, but it seems to me that what is really needed is a mechanism for userspace to do fine grained power control. There is such a mechanism, for USB at least. (Not well documented yet; I'm working on it.) If userspace wants to, it can disable autosuspend and do everything manually. Alan Stern - 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: [linux-usb-devel] question on flushing buffers and spinning down disk
No. You shouldn't expect users to run a program that would notice a particular disk drive hasn't been used in X minutes and then power it down. (Although they could if they wanted to... except that there's no way for userspace to know when the drive was most recently used.) I use noflushd to do userspace powerdowns for internal (ide) drives. - 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/2]: PCI Error Recovery: Symbios SCSI First Failure
On Thu, Sep 27, 2007 at 05:00:22PM -0500, Linas Vepstas wrote: On Wed, Sep 26, 2007 at 09:02:16AM -0600, Matthew Wilcox wrote: I'm a little concerned by the mention of MMIO. It's entirely possible for the sym2 driver to be using ioports to access the card rather than MMIO. Is it simply that it can't on the platform you test on? The comment is misleading. I've been in the bad habit of calling it mmio whenever its not DMA. OK, cool, thanks. I'll update the comment for you. One last thing (sorry, I only just noticed): In the error handler, we wait_for_completion(io_reset_wait). In sym2_io_error_detected, we init_completion(io_reset_wait). Isn't it possible that we hit the error handler before we hit the io_error_detected path, and thus the completion wait is lost? Since the completion is already initialised in sym_attach(), I don't think we need to initialise it in sym2_io_error_detected(). Makes sense to just delete it? -- 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: generating a Linux WWN?
Matthew Wilcox wrote: On Thu, Sep 27, 2007 at 09:16:13AM -0500, [EMAIL PROTECTED] wrote: Unfortunately, it looks like IEEE doesn't have any OID's registered for Linux or other reserved areas (http://standards.ieee.org/regauth/oui/oui.txt). However, it does look like they go in order... so maybe if you used an OID of 0xFF you could at least guarantee that you didn't conflict with any company's SAS WWNs. It's something that happens frequently enough that we should come up with a proper way of handling this. I heard a story of someone at HP taking an old computer, reading the MAC address from the motherboard, then snapping the board in half. I suppose if you're going to use a MAC address from a 10Mbit ethernet card for a SAS WWN, there's no chance of conflict, but still ... 3com might choose to do the same thing, and then we're in trouble. I don't have a good solution for WWN assignment. Even if we get a 24-bit OID assignment for 'software use' or something, how do we control the use withi the SAN to be sure we get no overlapping WWNs? To a perfectionist, there are no good answers besides try your best. The popular solutions I've seen are: 1) Random bytes, or fixed id + random bytes. Even on a worldwide net, collisions are highly unlikely. 2) [pseudo-]hash of reasonably static properties of your platform. 3) Admin makes a site-specific decision, blending cases #1 and #2 with other schemes such as site-defined numbering. In the ethernet world, all the drivers permit programmable MAC addresses, and many generate a random MAC if one is unavailable through other means. In practice this is deployed rarely, though things like bonding and seamless failover are making much more use of programmable MAC addresses than ever before. For case #2, one might consider creating a WWN for an ATA device that lacks one (they often do, even with a defined WWN field), by hashing the vendor id, firmware rev, and media serial number together. But even with such hueristics, persistence and uniqueness are difficult to recreate. With either case 1 or 2 -- both have seen success in the field -- you are essentially relying on luck after a certain point. And that's life. 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: Record the WWN of your SAS / FC port so that if/when it goes missing you can put it back? Have spares on site? Linux: not just for million dollar data centers any more :) (sorry, couldn't resist :)) More seriously, SAS will be making an increasing appearance on commodity hardware, through the new SAS/SATA chips that are just starting to make their appearance (like the chips I'm working on). And Marvell and Broadcom are big guys. Just wait until the tiny Taiwanese shops start cranking out SAS/SATA chips. With that, you'll get all the joys of low-cost volume production, and the user field foibles that come with it. 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] SCSI: export sas_hash_addr()
On Wed, 2007-09-26 at 03:35 -0400, Jeff Garzik wrote: sas_hash_addr() is the spec-defined standard hashing function. Make it available to drivers that need it. I'm not opposed in principle to exporting this, but I have a hard time understanding why a driver would need it. The hashed address is a property of the constructed SAS frames, which is done in libsas. The driver shouldn't really be calculating its own hash instead of using what libsas provides ... or is this because the hashed self address isn't calculated by the HBA so it needs to be programmed or something? 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
[PATCH] aic94xx: fix SMP request DMA direction
Unless I'm missing something, the SMP request goes /to/ the PCI device :) Signed-off-by: Jeff Garzik [EMAIL PROTECTED] --- drivers/scsi/aic94xx/aic94xx_task.c |4 - 2 files changed, 83 insertions(+), 17 deletions(-) diff --git a/drivers/scsi/aic94xx/aic94xx_task.c b/drivers/scsi/aic94xx/aic94xx_task.c index d5d8cab..ab13824 100644 --- a/drivers/scsi/aic94xx/aic94xx_task.c +++ b/drivers/scsi/aic94xx/aic94xx_task.c @@ -451,7 +451,7 @@ static int asd_build_smp_ascb(struct asd_ascb *ascb, struct sas_task *task, struct scb *scb; pci_map_sg(asd_ha-pcidev, task-smp_task.smp_req, 1, - PCI_DMA_FROMDEVICE); + PCI_DMA_TODEVICE); pci_map_sg(asd_ha-pcidev, task-smp_task.smp_resp, 1, PCI_DMA_FROMDEVICE); @@ -486,7 +486,7 @@ static void asd_unbuild_smp_ascb(struct asd_ascb *a) BUG_ON(!task); pci_unmap_sg(a-ha-pcidev, task-smp_task.smp_req, 1, -PCI_DMA_FROMDEVICE); +PCI_DMA_TODEVICE); pci_unmap_sg(a-ha-pcidev, task-smp_task.smp_resp, 1, PCI_DMA_FROMDEVICE); } - 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
