Re: [PATCH v2] libata: Simulate REPORT LUNS for ATAPI devices
On Mon, Dec 04, 2006 at 03:32:20PM -0800, Darrick J. Wong wrote:
The Quantum GoVault SATAPI removable disk device returns ATA_ERR in
response to a REPORT LUNS packet. If this happens to an ATAPI device
that is attached to a SAS controller (this is the case with sas_ata),
the device does not load because SCSI won't touch a SCSI device
that won't report its LUNs. Since most ATAPI devices don't support
multiple LUNs anyway, we might as well fake a response like we do for
ATA devices.
If the REPORT LUNS fails, we should fall back to a sequential scan.
Is (or why isn't) the error propagated back to scsi?
Signed-off-by: Darrick J. Wong [EMAIL PROTECTED]
---
drivers/ata/libata-scsi.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 47ea111..5ecf260 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -2833,8 +2833,13 @@ static inline int __ata_scsi_queuecmd(st
rc = ata_scsi_translate(dev, cmd, done, xlat_func);
else
ata_scsi_simulate(dev, cmd, done);
- } else
- rc = ata_scsi_translate(dev, cmd, done, atapi_xlat);
+ } else {
+ /* Simulate REPORT LUNS for ATAPI devices */
+ if (cmd-cmnd[0] == REPORT_LUNS)
+ ata_scsi_simulate(dev, cmd, done);
+ else
+ rc = ata_scsi_translate(dev, cmd, done, atapi_xlat);
+ }
return rc;
}
-- Patrick Mansfield
-
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: Don't be so verbose if no disc is present
Hi ... did you try James' patch? Looks like the same problem. Patch here: http://marc.theaimsgroup.com/?l=linux-scsim=112585164819923w=2 Was hidden within some other thread ... On Fri, Sep 09, 2005 at 11:17:16PM +0100, Daniel Drake wrote: Running a simple touch /dev/scd0 on a SCSI cdrom will cause the following message to appear in the logs if no disc is present: Device not ready. Make sure there is a disc in the drive. This results in the logs being flooded for some users by those userspace agents which repeatedly poll the device for media change. This patch demotes the message to a quieter scsi-logging message only. Signed-off-by: Daniel Drake [EMAIL PROTECTED] - 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: [GIT PATCH] SCSI merge for 2.6.13
On Tue, Sep 06, 2005 at 07:37:32PM -0500, James Bottomley wrote: This should be the entire contents of the SCSI tree I've been saving. It also includes Jens' send SCSI requests via bios tree that he, Mike Christie and I have been working on. The patch is available here: master.kernel.org:/pub/linux/kernel/scm/jejb/scsi-for-linus-2.6.git o convert ch to use scsi_execute_req o convert sr to scsi_execute_req o convert sd to scsi_execute_req (and update the scsi_execute_req API) o convert SPI transport class to scsi_execute o convert the remaining mid-layer pieces to scsi_execute_req The scsi_execute() retries argument is still not used. How is this going to work? For example, multiple unit attentions (power on / reset) during scanning. We send REPORT LUN, READ CAPACITY, etc., and would not retry if we got a unit attention. -- Patrick Mansfield - 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: Pending patches
On Tue, Sep 06, 2005 at 04:17:53PM -0400, Alan Stern wrote: I never received any word back after submitting them, and they aren't present in the source tree at http://www.parisc-linux.org/cgi-bin/gitweb.pl Is it possible to get these patches into the queue? Not that your patches are in it, but the scsi-misc tre is at: http://www.kernel.org/git/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=summary -- Patrick Mansfield - 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 scsi-misc-2.6] scsi_debug testing patch, return LUN 0 with PQ 3
Just a patch for scanning with PQ == 3 for LUN 0, only for use in testing
previous patch, don't apply.
diff -uprN -X /home/patman/dontdiff scsi-misc-2.6/drivers/scsi/scsi_debug.c
lun0-replun-scsi-misc-2.6/drivers/scsi/scsi_debug.c
--- scsi-misc-2.6/drivers/scsi/scsi_debug.c 2005-07-26 11:08:51.0
-0700
+++ lun0-replun-scsi-misc-2.6/drivers/scsi/scsi_debug.c 2005-07-27
18:24:05.0 -0700
@@ -619,7 +619,10 @@ static int resp_inquiry(struct scsi_cmnd
alloc_len = (cmd[3] 8) + cmd[4];
memset(arr, 0, SDEBUG_MAX_INQ_ARR_SZ);
- pq_pdt = (scsi_debug_ptype 0x1f);
+ if (devip-lun == 0)
+ pq_pdt = 0x7f;
+ else
+ pq_pdt = (scsi_debug_ptype 0x1f);
arr[0] = pq_pdt;
if (0x2 cmd[1]) { /* CMDDT bit set */
mk_sense_buffer(devip, ILLEGAL_REQUEST, INVALID_FIELD_IN_CDB,
-
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 scsi-misc-2.6] allow REPORT LUN scanning even for LUN 0 PQ of 3
James -
Can you ack or comment?
Allow REPORT LUN scanning even if LUN 0 reports a peripheral qualifier of
3 (effectively no storage is available on LUN 0).
Similar patch I previously posted:
http://marc.theaimsgroup.com/?l=linux-scsim=110297733824960w=2
There is also Hannes patch, it leaves LUN 0 available for use via user
space, for compatibility it likely requires that it stay visible in the
future:
http://marc.theaimsgroup.com/?l=linux-scsim=111692497200507w=2
Hannes' patch also causes a lot of extra vSCSI devices to show up on some
platforms :)
Signed-off-by: Patrick Mansfield [EMAIL PROTECTED]
diff -uprN -X /home/patman/dontdiff scsi-misc-2.6.git/drivers/scsi/scsi_scan.c
lun0-scsi-misc-2.6.git/drivers/scsi/scsi_scan.c
--- scsi-misc-2.6.git/drivers/scsi/scsi_scan.c 2005-08-16 15:02:20.0
-0700
+++ lun0-scsi-misc-2.6.git/drivers/scsi/scsi_scan.c 2005-08-30
14:59:15.0 -0700
@@ -64,14 +64,14 @@
* SCSI_SCAN_NO_RESPONSE: no valid response received from the target, this
* includes allocation or general failures preventing IO from being sent.
*
- * SCSI_SCAN_TARGET_PRESENT: target responded, but no device is available
+ * SCSI_SCAN_LUN_IGNORED: target responded, but no device is available
* on the given LUN.
*
* SCSI_SCAN_LUN_PRESENT: target responded, and a device is available on a
* given LUN.
*/
#define SCSI_SCAN_NO_RESPONSE 0
-#define SCSI_SCAN_TARGET_PRESENT 1
+#define SCSI_SCAN_LUN_IGNORED 1
#define SCSI_SCAN_LUN_PRESENT 2
static char *scsi_null_device_strs = nullnullnullnull;
@@ -578,7 +578,7 @@ static void scsi_probe_lun(struct scsi_r
/*
* The scanning code needs to know the scsi_level, even if no
-* device is attached at LUN 0 (SCSI_SCAN_TARGET_PRESENT) so
+* device is attached at LUN 0 (SCSI_SCAN_LUN_IGNORED) so
* non-zero LUNs can be scanned.
*/
sdev-scsi_level = inq_result[2] 0x07;
@@ -769,6 +769,19 @@ static int scsi_add_lun(struct scsi_devi
return SCSI_SCAN_LUN_PRESENT;
}
+/*
+ * scsi_scan_remove: Helper funciton to free up sdev's that are not added
+ * as sys devices. That is, we never call scsi_probe_and_add_lun for these
+ * sdev's.
+ */
+static void scsi_scan_remove(struct scsi_device *sdev)
+{
+ if (sdev-host-hostt-slave_destroy)
+ sdev-host-hostt-slave_destroy(sdev);
+ transport_destroy_device(sdev-sdev_gendev);
+ put_device(sdev-sdev_gendev);
+}
+
/**
* scsi_probe_and_add_lun - probe a LUN, if a LUN is found add it
* @starget: pointer to target device structure
@@ -783,8 +796,10 @@ static int scsi_add_lun(struct scsi_devi
*
* Return:
* SCSI_SCAN_NO_RESPONSE: could not allocate or setup a Scsi_Device
- * SCSI_SCAN_TARGET_PRESENT: target responded, but no device is
- * attached at the LUN
+ * SCSI_SCAN_LUN_IGNORED: target responded, but no device is
+ * attached at the LUN. The sdev is never made visible, and must
+ * be freed by the caller via scsi_scan_remove(). This way, LUN 0
+ * is avaiable for use with the REPORT LUN command.
* SCSI_SCAN_LUN_PRESENT: a new Scsi_Device was allocated and initialized
**/
static int scsi_probe_and_add_lun(struct scsi_target *starget,
@@ -853,7 +868,7 @@ static int scsi_probe_and_add_lun(struct
SCSI_LOG_SCAN_BUS(3, printk(KERN_INFO
scsi scan: peripheral qualifier of 3,
no device added\n));
- res = SCSI_SCAN_TARGET_PRESENT;
+ res = SCSI_SCAN_LUN_IGNORED;
goto out_free_result;
}
@@ -872,17 +887,13 @@ static int scsi_probe_and_add_lun(struct
out_free_sreq:
scsi_release_request(sreq);
out_free_sdev:
- if (res == SCSI_SCAN_LUN_PRESENT) {
+ if ((res == SCSI_SCAN_LUN_PRESENT) || (res == SCSI_SCAN_LUN_IGNORED)) {
if (sdevp) {
scsi_device_get(sdev);
*sdevp = sdev;
}
- } else {
- if (sdev-host-hostt-slave_destroy)
- sdev-host-hostt-slave_destroy(sdev);
- transport_destroy_device(sdev-sdev_gendev);
- put_device(sdev-sdev_gendev);
- }
+ } else
+ scsi_scan_remove(sdev);
out:
return res;
}
@@ -1228,7 +1239,8 @@ static int scsi_report_lun_scan(struct s
from %s lun %d while scanning, scan
aborted\n, devname, lun);
break;
- }
+ } else if (res == SCSI_SCAN_LUN_IGNORED)
+ scsi_scan_remove(sdev);
}
}
@@ -1262,6 +1274,8 @@ struct scsi_device *__scsi_add_device(st
if (scsi_host_scan_allowed(shost)) {
res = scsi_probe_and_add_lun(starget
Re: new qla2xxx driver breaks SAN setup with 2 controllers
-scan_mutex);
@@ -1337,7 +1352,8 @@ void scsi_scan_target(struct device *par
/*
* Scan for a specific host/chan/id/lun.
*/
- scsi_probe_and_add_lun(starget, lun, NULL, NULL, rescan, NULL);
+ res = scsi_probe_and_add_lun(starget, lun, NULL, sdev,
+rescan, NULL);
goto out_reap;
}
@@ -1345,8 +1361,11 @@ void scsi_scan_target(struct device *par
* Scan LUN 0, if there is some response, scan further. Ideally, we
* would not configure LUN 0 until all LUNs are scanned.
*/
- res = scsi_probe_and_add_lun(starget, 0, bflags, sdev, rescan, NULL);
- if (res == SCSI_SCAN_LUN_PRESENT) {
+ lun = 0;
+ res = scsi_probe_and_add_lun(starget, lun, bflags, sdev, rescan,
+NULL);
+ WARN_ON(!sdev res != SCSI_SCAN_NO_RESPONSE);
+ if (sdev res != SCSI_SCAN_NO_RESPONSE)
if (scsi_report_lun_scan(sdev, bflags, rescan) != 0)
/*
* The REPORT LUN did not scan the target,
@@ -1354,20 +1373,12 @@ void scsi_scan_target(struct device *par
*/
scsi_sequential_lun_scan(starget, bflags,
res, sdev-scsi_level, rescan);
- } else if (res == SCSI_SCAN_TARGET_PRESENT) {
- /*
-* There's a target here, but lun 0 is offline so we
-* can't use the report_lun scan. Fall back to a
-* sequential lun scan with a bflags of SPARSELUN and
-* a default scsi level of SCSI_2
-*/
- scsi_sequential_lun_scan(starget, BLIST_SPARSELUN,
- SCSI_SCAN_TARGET_PRESENT, SCSI_2, rescan);
- }
if (sdev)
scsi_device_put(sdev);
out_reap:
+ if ((lun == 0) (res == SCSI_SCAN_LUN_IGNORED))
+ scsi_scan_remove(sdev);
/* now determine if the target has any children at all
* and if not, nuke it */
scsi_target_reap(starget);
-- Patrick Mansfield
-
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] minimal SAS transport class
On Wed, Aug 24, 2005 at 04:05:03PM -0400, Luben Tuikov wrote: On 08/24/05 13:12, Patrick Mansfield wrote: On Tue, Aug 23, 2005 at 07:55:37PM -0400, Luben Tuikov wrote: Where does udev get its label? You can call any script or program from udev and use the result. There are And where does _it_ get it? You can write a program to supply it :) And then try to get it into your favourite distribution ... recent changes for persistent naming, the /dev/by-id naming used in sles9 is in current udev. A tmp /dev node is available to called out programs, so any pass through or regular IO can be sent to the device before it has its real name. So you should be able to get anything available on the scsi device that way. *SCSI DEVICE*, not SAS of FC or iSCSI or whatever. Now, where will that *scsi device* get _its_ label? udev now has an IMPORT rule, see usage of scsi_id, vol_id, etc. in current udev rules. Followup posts should go to [EMAIL PROTECTED] Hey Patrick, is there a point to this thread? Yes, at this juncture a simplified explanation about udev rules. If you have an idea, please go ahead and share and/or implement it. If you're unclear on something please ask it directly. I thought you were asking for details about udev ... your question was rather ambiguous. -- Patrick Mansfield - 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] minimal SAS transport class
On Sat, Aug 20, 2005 at 12:15:41AM -0400, [EMAIL PROTECTED] wrote: - the target id is logical for everything but SPI For FC, target ids are typically assigned to devices on a 1st-seen-1st-assigned basis. For several reasons, there can be changes in port discovery order after link events (cable pulls, etc). For 2.4 kernels, the driver typically maintained a mapping within the driver to ensure the same device showed up at the same target id, even if it disappeared for some amount of time. If FC was the boot device, wacky methods were used to ensure the mapping persisted boot-to-boot. As others stated, id is already a tag/label. You should be able to pass whatever id you want to scsi_scan_target, like the FC ID (port_id), and then we also want an abstract iterator in fc transport for the id for usage in scsi_scan.c:scsi_scan_channel. Then you can lose all the fc_host-next_target_id code. Printing of them won't be so nice, we should have used hex values in our device's bus_id. Hex would also make scsi class/bus_id shorter. We can in theory overflow it today: (5 digits per short + 10 digits per int * 3 + 3 :'s) = 38 But BUS_ID_SIZE (KOBJ_NAME_LEN) is 20. 8 byte lun would add on another 10 bytes (if in decimal). We generally don't have problems since channel is one digit (it should be a char or bit), id is 100, and host 1000 ... lun I'm not sure about: (3 + 1 + 2 + 10) + 3 = 19. i.e. use port_id as the id (8 digits?) and we are more likely to go above 20. -- Patrick Mansfield - 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: /proc/scsi/scsi patch for large number of devices
On Tue, Aug 23, 2005 at 06:42:06PM +0100, Christoph Hellwig wrote: We had this before, and the answer is: don't use /proc/scsi if you have lots of device. Don't even enable the config option. We still don't have sysfs scsi devinfo support, we need to represent it as a modifiable list or such under sysfs. -- Patrick Mansfield - 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] correct attribute_container list usage
On Mon, Aug 22, 2005 at 03:14:27PM -0700, Patrick Mansfield wrote:
Attached is a test module, it oopsed for me with CONFIG_DEBUG_SLAB, on
ppc64. I was trying to complete testing of my hack (on current git tree,
rather than scsi-misc), but have been preempted by other work today.
The patch worked OK for rmmod qla2300.
OK ... really attached it this time.
#include linux/config.h
#include linux/module.h
#include linux/kernel.h
#include linux/sched.h
#include linux/errno.h
#include linux/timer.h
#include linux/types.h
#include linux/string.h
#include linux/genhd.h
#include linux/fs.h
#include linux/init.h
#include linux/proc_fs.h
#include linux/moduleparam.h
static int dev_child_state = 1;
MODULE_AUTHOR(Patrick Mansfield);
MODULE_DESCRIPTION(test device_for_each_child);
MODULE_LICENSE(GPL);
static struct device dev_child_main, *dev_child_child;
static void some_release(struct device *dev)
{
printk(KERN_WARNING enter %s to kfree %s\n, __FUNCTION__,
dev-bus_id);
kfree(dev);
printk(KERN_WARNING exit %s\n, __FUNCTION__);
}
/*
* Add one device under dev_child_main.
*/
static void dev_child_create(void)
{
struct device *dev;
printk(KERN_WARNING enter %s\n, __FUNCTION__);
dev = kmalloc(sizeof (*dev), GFP_KERNEL);
if (!dev) {
printk(KERN_WARNING %s can't get dev\n, __FUNCTION__);
return;
}
memset(dev, 0, sizeof(*dev));
dev-parent = dev_child_main;
dev-release = some_release;
sprintf(dev-bus_id, child-1);
device_register(dev);
dev_child_child = dev;
printk(KERN_WARNING exit %s, added %s\n, __FUNCTION__,
dev-bus_id);
}
/*
* Remove dev_child_child.
*/
static void dev_child_destroy_ok(void)
{
printk(KERN_WARNING enter %s\n, __FUNCTION__);
if (dev_child_child) {
get_device(dev_child_main);
device_unregister(dev_child_child);
dev_child_child = NULL;
put_device(dev_child_main);
}
printk(KERN_WARNING exit %s\n, __FUNCTION__);
}
static int remove_child(struct device *dev, void *data)
{
printk(KERN_WARNING enter %s\n, __FUNCTION__);
device_unregister(dev);
printk(KERN_WARNING exit %s\n, __FUNCTION__);
return 0;
}
/*
* Remove all children of dev_child_main
*/
static void dev_child_destroy_fails(void)
{
printk(KERN_WARNING enter %s\n, __FUNCTION__);
get_device(dev_child_main);
device_for_each_child(dev_child_main, NULL, remove_child);
put_device(dev_child_main);
dev_child_child = NULL;
printk(KERN_WARNING exit %s\n, __FUNCTION__);
}
static int dev_child_set_state(const char *val, struct kernel_param *kp)
{
int new_state;
switch(val[0]) {
case '0':
new_state = 0;
break;
case '1':
new_state = 1;
break;
case '2':
new_state = 2;
break;
default:
return -EINVAL;
}
if (new_state != dev_child_state) {
dev_child_state = new_state;
if (dev_child_state == 0)
dev_child_create();
else if (dev_child_state == 1)
dev_child_destroy_ok();
else /* 2 */
dev_child_destroy_fails();
return 0;
} else
return -E2BIG;
return 0;
}
module_param_call(state, dev_child_set_state, param_get_int,
dev_child_state, 0644);
static void dev_child_0_release(struct device * dev)
{
}
static struct device dev_child_primary = {
.bus_id = pseudo-dev_child,
.release= dev_child_0_release,
};
static int dev_child_bus_match(struct device *dev,
struct device_driver *dev_driver)
{
return 1;
}
static struct bus_type dev_child_bus = {
.name = dev_child_bus,
.match = dev_child_bus_match,
};
static int dev_child_probe(struct device *dev)
{
int error = 0;
return error;
}
static int dev_child_remove(struct device *dev)
{
int error = 0;
dev_child_destroy_ok();
return error;
}
static struct device_driver dev_child_sys_driver = {
.name = dev_child,
.bus= dev_child_bus,
.probe = dev_child_probe,
.remove = dev_child_remove,
};
static void dev_child_release(struct device *dev)
{
}
static void add_main(void)
{
struct device *dev = dev_child_main;
int error;
/* add one device to our pseudo bus */
device_initialize(dev);
dev-bus = dev_child_bus;
dev-parent = dev_child_primary;
dev-release = dev_child_release;
strcpy(dev-bus_id, dev_child_main);
error
Re: [PATCH] correct attribute_container list usage
On Mon, Aug 22, 2005 at 06:26:25PM -0500, James Bottomley wrote:
On Mon, 2005-08-22 at 17:47 -0500, James Bottomley wrote:
One apparent, but rather nasty, solution would be to embed object get
and put into the klist head as functions that take the node, so
klist_next would take the object reference as well as the list kref,
then drop it on klist_release.
Well, I'm not enormously fond of this, but it's not as downright nasty
as I thought. Patrick, could you try this (assuming you have a fast
machine ... I'll be done with the complete kernel rebuild that touching
klist.h requires eventually) you'll have to encode klist to device get
and put functions and feed them to klist_init_embedded().
But, we have to pass in a struct kref, to affect put/get_device, correct?
While klist (and your patch) need klist_node. These pieces:
+ void(*get)(struct klist_node *);
+ void(*put)(struct klist_node *);
+void klist_init_embedded(struct klist * k, void (*get)(struct klist_node *),
+ void (*put)(struct klist_node *))
{
INIT_LIST_HEAD(k-k_list);
spin_lock_init(k-k_lock);
+ k-get = get;
+ k-put = put;
}
In include/linux/device.h we have:
struct device {
...
struct kobject kobj;
...
}
And get/put_device are:
struct kobject * kobject_get(struct kobject * kobj)
{
if (kobj)
kref_get(kobj-kref);
return kobj;
}
And then:
void kref_get(struct kref *kref)
{
WARN_ON(!atomic_read(kref-refcount));
atomic_inc(kref-refcount);
}
-- Patrick Mansfield
-
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] correct attribute_container list usage
On Mon, Aug 22, 2005 at 09:03:03PM -0500, James Bottomley wrote: On Mon, 2005-08-22 at 17:39 -0700, Patrick Mansfield wrote: But, we have to pass in a struct kref, to affect put/get_device, correct? Correct. Let me post the code mods to drivers/base/core.c so you can see how it works. OK ... I thought that was what you intended but could not quite see it. Incidentally, it now passes your dev_child test without causing a slab corruption. Great, tested with your two patches applied on recent 2.6.13-rc6-git tree, and modprobe -r qla2300 now works fine. -- Patrick Mansfield - 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: libata error handling
On Fri, Aug 19, 2005 at 02:46:35PM -0400, Luben Tuikov wrote: Using the command time out hook and the strategy routine, gives _complete_ control over host recovery, and I really do mean _complete_. I assume you mean hostt-eh_timed_out. Is anyone implmenting (or has implemented) a -eh_timed_out function? I see none in mainline kernel. I was looking at using it in an LLDD, but hit two problems, and have started to work on an alternate approach of cancelling (aborting or wtf you want to call it) a list of commands in the eh thread. The two problems I see with the hook are: It calls the driver in interrupt context, so the called function can't sleep. There is no queueing or list mechanism, so LLDD's that can only cancel one command at a time will have problem. -- Patrick Mansfield - 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: libata error handling
On Fri, Aug 19, 2005 at 04:03:15PM -0400, Luben Tuikov wrote: On 08/19/05 15:38, Patrick Mansfield wrote: On Fri, Aug 19, 2005 at 02:46:35PM -0400, Luben Tuikov wrote: Using the command time out hook and the strategy routine, gives _complete_ control over host recovery, and I really do mean _complete_. I assume you mean hostt-eh_timed_out. Hi Patrick, how are you? Good thanks :) I was looking at using it in an LLDD, but hit two problems, and have started to work on an alternate approach of cancelling (aborting or wtf you want to call it) a list of commands in the eh thread. The eh_timed_out + eh_strategy_handler is actually pretty perfect, and _complete_, for any application and purpose in recovering a One other point: Another problems is that we quiesce all shost IO before waking up the eh. I was changing it to wakeup the eh even while other IO is outstanding, so the eh can wakeup and cancel individual commands while other IO is still using the HBA. The two problems I see with the hook are: It calls the driver in interrupt context, so the called function can't sleep. Consider this: When SCSI Core told you that the command timed out, A) it has already finished, B) it hasn't already finished. In case A, you can return EH_HANDLED. In case B, you return EH_NOT_HANDLED, and deal with it in the eh_strategy_handler. So, for EH_NOT_HANDLED, do you add the scmd to a LLDD list in your eh_timed_out, then wait for the eh to run? Or maybe your host can_queue is 1 :) (Hint: you can still finish it from there.) EH_RESET_TIMER is not really needed provided that - your interface infrastructure is in place, - you set the timeout value properly in slave_configure. There is no queueing or list mechanism, so LLDD's that can only cancel one command at a time will have problem. See above. I don't see it ... hence my question above. -- Patrick Mansfield - 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: libata error handling
Luben - On Fri, Aug 19, 2005 at 04:43:41PM -0400, Luben Tuikov wrote: On 08/19/05 16:11, Patrick Mansfield wrote: I was changing it to wakeup the eh even while other IO is outstanding, so the eh can wakeup and cancel individual commands while other IO is still using the HBA. Hmm, if you want to do this, then SCSI Core needs to know about: - Domain, - Domain device and - LU. Not really, scsi core is just asking the LLDD to cancel or release the scmd. That is really all we do in the eh today, and then if the LLDD can't cancel the scmd, we take other sometimes less than useful steps. The LLDD could start any error handling scheme it wants, independent of scsi core action. We don't initiate error handling in scsi core for other error cases, why should a timeout be any different? The reason, is that you do not know why a task timed out. Is it the LU, is it the device, is it the domain? Right, so in scsi core allow a simple method that can cancel commands while the HBA is still in use. (Those are concepts talked about in SAM.) Since currently, SCSI Core has no clue about those concepts, the current infrastructure, stalling IO to the host on eh, satisfies. So, for EH_NOT_HANDLED, do you add the scmd to a LLDD list in your eh_timed_out, then wait for the eh to run? No, no Patrick, I don't. The SCSI Core does this for me, and then calls my eh_strategy routine and all the commands are on the list. Oh right ... I was not thinking straight. But I don't see how that gains much, if you sometimes still wait for scsi core to quiesce IO and wakeup the eh. -- Patrick Mansfield - 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: [RFC] add global timeout to the scsi mid-layer
On Fri, Aug 05, 2005 at 09:45:40PM -0500, James Bottomley wrote:
There are certain rogue devices (and the aic7xxx driver) that return
BUSY or QUEUE_FULL forever. This code will apply a global timeout (of
the total number of retries times the per command timer) to a given
command. If it is exceeded, the command is completed regardless of its
state.
Good idea ... sorry I'm late with comments ...
Move the check into scsi_decide_disposition.
It is not clear if DID_IMM_RETRY should ever get a SUCCESS.
What about completely removing cmd-allowed, and only using total time (a
new cmd-io_lifetime, wait_for in your patch) that the IO has been
outstanding as a retry limiter?
Or have allowed and io_lifetime co-exist, I'm not sure which values should
used as the lower or upper limit.
scmd-allowed (and io_lifetime) should be modifiable from user space and
set in uppper levels, like sdev-timeout, instead of hardcoding to the
timeout * allowed.
-- Patrick Mansfield
James
diff --git a/drivers/scsi/advansys.c b/drivers/scsi/advansys.c
--- a/drivers/scsi/advansys.c
+++ b/drivers/scsi/advansys.c
@@ -9200,8 +9200,8 @@ asc_prt_scsi_cmnd(struct scsi_cmnd *s)
(unsigned) s-serial_number, s-retries, s-allowed);
printk(
- timeout_per_command %d, timeout_total %d, timeout %d\n,
-s-timeout_per_command, s-timeout_total, s-timeout);
+ timeout_per_command %d\n,
+s-timeout_per_command);
printk(
scsi_done 0x%lx, done 0x%lx, host_scribble 0x%lx, result 0x%x\n,
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -268,6 +268,7 @@ struct scsi_cmnd *scsi_get_command(struc
} else
put_device(dev-sdev_gendev);
+ cmd-jiffies_at_alloc = jiffies;
return cmd;
}
EXPORT_SYMBOL(scsi_get_command);
@@ -798,9 +799,23 @@ static void scsi_softirq(struct softirq_
while (!list_empty(local_q)) {
struct scsi_cmnd *cmd = list_entry(local_q.next,
struct scsi_cmnd, eh_entry);
+ /* The longest time any command should be outstanding is the
+ * per command timeout multiplied by the number of retries.
+ *
+ * For a typical command, this is 2.5 minutes */
+ unsigned long wait_for
+ = cmd-allowed * cmd-timeout_per_command;
list_del_init(cmd-eh_entry);
disposition = scsi_decide_disposition(cmd);
+ if (disposition != SUCCESS
+ time_before(cmd-jiffies_at_alloc + wait_for, jiffies)) {
+ dev_printk(KERN_ERR, cmd-device-sdev_gendev,
+timing out command, waited %ds\n,
+wait_for/HZ);
+ disposition = SUCCESS;
+ }
+
scsi_log_completion(cmd, disposition);
switch (disposition) {
case SUCCESS:
diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h
--- a/include/scsi/scsi_cmnd.h
+++ b/include/scsi/scsi_cmnd.h
@@ -51,12 +51,16 @@ struct scsi_cmnd {
* printk's to use -pid, so that we can kill this field.
*/
unsigned long serial_number;
+ /*
+ * This is set to jiffies as it was when the command was first
+ * allocated. It is used to time how long the command has
+ * been outstanding
+ */
+ unsigned long jiffies_at_alloc;
int retries;
int allowed;
int timeout_per_command;
- int timeout_total;
- int timeout;
unsigned char cmd_len;
unsigned char old_cmd_len;
-
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.13-rc6-latest] SCSI disk registration msgs repeat themselves
On Tue, Aug 16, 2005 at 10:51:13PM -0700, Pete Zaitcev wrote:
On Tue, 16 Aug 2005 21:39:33 -0700, Patrick Mansfield [EMAIL PROTECTED]
wrote:
On Tue, Aug 16, 2005 at 11:01:30PM -0400, Chuck Ebbert wrote:
I just added some usb-storage devices to my system and got the below.
Why do the first four lines repeat for each device? (Not sure if
this is a SCSI or USB problem.)
It is in the partition code. I posted twice before about this with no
response.
It's not an important problem, presumably. I observe dual revalidations
as well, but they are not that bothersome. Add to it that your patch
Yes.
Does this *only* happens for sd (scsi) devices?
appears wrong (see below). If you offered an acceptable solution, I would
expect a warmer welcome... But even then getting a reply from linux-scsi
folks is like pulling a tooth (if my own little CD-ROM sizing patch is
any indication). So, steel yourself for challenges of this life, Patrick!
;-)
Here's what it was in 2.6.9, as documented in drivers/block/ub.c:
+ /*
+ * This is a workaround for a specific problem in our block layer.
+ * In 2.6.9, register_disk duplicates the code from rescan_partitions.
+ * However, if we do add_disk with a device which persistently reports
+ * a changed media, add_disk calls register_disk, which does do_open,
+ * which will call rescan_paritions for changed media. After that,
+ * register_disk attempts to do it all again and causes double kobject
+ * registration and a eventually an oops on module removal.
+ *
+ * The bottom line is, Al Viro says that we should not allow
+ * bdev-bd_invalidated to be set when doing add_disk no matter what.
+ */
+ if (sc-first_open) {
+ if (sc-changed) {
+ sc-first_open = 0;
+ rc = -ENOMEDIUM;
+ goto err_open;
+ }
+ }
Users were hitting it with oopses like these:
http://www.ussg.iu.edu/hypermail/linux/kernel/0409.2/0011.html
The ub alone was not suffient to motivate Al for the fix, so I added
this silly first_open thingie, which papered over it. It was thought
that sd was miraclously immune.
However, over time users hit it with usb-storage and sd, like this:
http://lkml.org/lkml/2004/2/21/19
This prompted Al's action. He simply dropped all the extra code like
this:
--- linux-2.6.9-11.5.EL/fs/partitions/check.c 2004-10-18 14:55:07.0
-0700
+++ linux-2.6.12/fs/partitions/check.c2005-06-17 12:48:29.0
-0700
@@ -358,24 +357,9 @@ void register_disk(struct gendisk *disk)
if (!bdev)
return;
+ bdev-bd_invalidated = 1;
if (blkdev_get(bdev, FMODE_READ, 0) 0)
return;
- state = check_partition(disk, bdev);
- if (state) {
- for (j = 1; j state-limit; j++) {
- sector_t size = state-parts[j].size;
- sector_t from = state-parts[j].from;
- if (!size)
- continue;
- add_partition(disk, j, from, size);
-#ifdef CONFIG_BLK_DEV_MD
- if (!state-parts[j].flags)
- continue;
- md_autodetect_dev(bdev-bd_dev+j);
-#endif
- }
- kfree(state);
- }
blkdev_put(bdev);
}
OK, thanks for posting those links and information.
--- linux-2.6.11-rc1/fs/partitions/check.c Fri Dec 24 13:35:28 2004
+++ no-double-sd-linux-2.6.11-rc1/fs/partitions/check.c Fri Jan 21
11:19:00 2005
@@ -375,8 +375,6 @@ int rescan_partitions(struct gendisk *di
bdev-bd_invalidated = 0;
for (p = 1; p disk-minors; p++)
delete_partition(disk, p);
- if (disk-fops-revalidate_disk)
- disk-fops-revalidate_disk(disk);
As for your proposed fix, it may be problematic. The -revalidate
method has to be called at least once for a new device, because
that's when drivers fetch the capacities. But -open only calls
check_disk_change() for removable devices. Who is going to call
-revalidate inside add_disk() for non-removable devices?
sd.c always calls its revalidate_disk method (sd_revalidate_disk) when the
device is attached, so for scsi, we definitely do not miss anything.
I thought revalidate_disk was not called prior to Al's patch, so why do we
need to call it on the first open now?
You already have to call set_capacity() before add_disk(), else
register_disk thinks there is no media present, and won't set
bd_invalidated. So drivers must already get the capacity (or fake it)
prior to calling add_disk.
-- Patrick Mansfield
-
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.13-rc6-latest] SCSI disk registration msgs repeat themselves
On Tue, Aug 16, 2005 at 11:01:30PM -0400, Chuck Ebbert wrote: I just added some usb-storage devices to my system and got the below. Why do the first four lines repeat for each device? (Not sure if this is a SCSI or USB problem.) It is in the partition code. I posted twice before about this with no response. The changelog said it was a workaround for a borken device, but not what device it was or any other details. There is a patch (against 2.6.11) in the below, I haven't tried it with recent kernels: http://marc.theaimsgroup.com/?l=linux-scsim=110719123625593w=2 http://marc.theaimsgroup.com/?l=linux-scsim=110848617107098w=2 -- Patrick Mansfield - 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: Unplugging of SBP-2 devices still does not work
Seeing sysrq-t stack traces might help debugging. On Sat, Jul 23, 2005 at 09:58:18PM +0200, Stefan Richter wrote: I wrote: Problem 1) Hot unplugging of SBP-2 hangs ieee1394's nodemgr [...] [unplug disk] Jul 23 20:08:53 shuttle kernel: ieee1394: Node changed: 1-01:1023 - 1-00:1023 Jul 23 20:08:53 shuttle kernel: ieee1394: Node suspended: ID:BUS[1-00:1023] GUID[0001d202e0200ef1] Jul 23 20:08:53 shuttle kernel: ieee1394: sbp2: sbp2_remove Jul 23 20:08:53 shuttle kernel: Synchronizing SCSI cache for disk sda: I should provide perhaps a little more background about nodemgr. It waits for events on the FireWire bus. If it detects physical removal of a node, it calls remove callbacks from IEEE 1394 protocol drivers such as sbp2. That's where sbp2_remove() kicks in. So it all happens in nodemgr's process context, although the hang occurs somewhere in the scsi mid or high level, or perhaps in the driver core when it is called from scsi. - 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: SCSI luns
On Tue, Jul 12, 2005 at 12:17:53PM -0400, James Bottomley wrote: Thanks for redirecting to the correct list. On Tue, 2005-07-12 at 13:38 +0200, Arjan van de Ven wrote: On Tue, 2005-07-12 at 16:52 +0530, Amrut Joshi wrote: Currently linux scsi subsystem doesnt store the 8-byte luns which are recieved in REPORT_LUNS reply. This information is forver lost once the scan is over. In my LDD I need this information. Currently I have to snoop REPORT_LUNS reply, do scsilun_to_int for all the luns and Our current transformation routine scsilun_to_int is bijective as long as the original scsi_lun doesn't overrun 32 bits (which it might well do one day). Why can't you simply do this by transforming back the lun? In general, I'm not in favour of adding redundant information to the device structure, so if you can demonstrate we overrun our allotted 32 bits, the solution is probably to take lun up to u64 and still do the back transform (the alternative being to substitute lun with it's structural equivalen which would entail a lot of pain throught the SCSI subsytem). James - There have been cases of going past 32 bits, though I have not seen specifics, storage devices are instead being configured to avoid the problem. Using some of those configurations has bad consequences. For example, one storage box enumerates the LUN numbering, but this means existing LUN values can change when a new LU is added (ugh)! Trying to have a compatible 64 bit LUN for all uses (change the current lun to u64) looks hard, given all of the odd mappings, having to deal with the high bits being set (for non-zero LU address methods), and trying to figure out whether the 64 bit LUN can fit into 32 bits (really about 8 bits for SPI, and 16 bits for some HBA's). Or by back transform did you mean change lun to u64, and conditionally map to 32 bits for drivers (currently all) that don't support a 64 bit LUN? H ... Printing the lun value for messages is odd/painful no matter how it is added, since for example, 64 bit value for LUN 1 is something like 0001 . Having both 32 and 64 bit versions makes it even odder. An sdev_printk() makes this easier, as we would have to print to conditionally print lun in both formats (old and new) depending on HBA support. But just adding a 64 bit LUN in parallel does not help much if the scan code is not modified (we'll fail to scan LUNs with higher bits set). -- Patrick Mansfield - 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: map gendisk (or blockdev) - scsi_device
On Wed, Jul 13, 2005 at 11:44:34AM -0700, Edward Falk wrote: You should revisit your code to not need access to the scsi_device structure, and follow the layering of the block and scsi subsystems. Maybe I should explain what I'm trying to do here. Some of our software reads some of the values in /proc/ide/hda/. We're porting this facility to libata-based drivers in 2.6 and moving it to /sysfs/block/sda/. The sysfs show() functions will be given pointers to gendisk structures but will need to obtain information from the associated scsi_device structure. Does anybody have any suggestions as to the right way to proceed? Add or use the attributes under the scsi_device, then use the /sysfs/block/sd/device symlink to find the corresponding scsi_device. This is similar to what udev and lsscsi use to find device attributes. udev uses libsysfs (included with udev). [elm3b79 patman]$ ls -l /sys/block/sdo/device lrwxrwxrwx1 root root0 Jul 13 16:44 /sys/block/sdo/device - ../../devices/pci:01/:01:0c.0/host2/rport-2:0-8/target2:0:8/2:0:8:0 [elm3b79 patman]$ ls /sys/block/sdo/device/ block device_blocked iodone_cnt modelrescan state vendor bus driver ioerr_cnt queue_depth rev timeout delete iocounterbits iorequest_cnt queue_type scsi_level type -- Patrick Mansfield - 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] Use device_for_each_child() to unregister devices in scsi_remove_target().
On Mon, Jul 11, 2005 at 05:20:12PM -0700, Greg KH wrote: On Tue, Jul 05, 2005 at 05:38:50PM -0700, Patrick Mansfield wrote: Hi Greg / Patrick - I'm getting an oops with current (pulled today) 2.6 git, the device_for_each_child() does not seem to be deletion safe. We hold the klist in place via the n_ref, but the kobj (in the struct device for the struct scsi_target) containing it is freed when the kref-refcount goes to zero. But we grab a reference to that object right before we call device_for_each_child(), right? Or am I missing something here? No, we get another reference on the passed in dev argument (in this failing case, it is for an FC's rport), not its children (scsi_target) that we want to iterate over. If all children (scsi_targets) are removed, then the put in scsi_remove_target() would (or could) set the rport refcount to zero and it would be deleted. But the scsi_target would already be gone. Cases that are not affected are passed a scsi_target: scsi_is_target_device(dev) is true and we won't even call device_for_each_child(). Adding another get/put in __remove_child() does *not* help either, as it is the code within device_for_each_child() that needs another get/put of the kref instead of a get/put on the klist (well its n_ref); and if you do that, I don't see how the locking can be done correctly. I thought we had some semaphores in scsi to protect calls to scsi_remove_target(), but I only see those for scsi_device scan/removal (the shost-scan_mutex). It looks like scsi should not allow removal and additions to happen at the same time on any scsi_target (and adding up/down on shost-scan_mutex won't fix this problem). -- Patrick Mansfield - 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: Perform uncached reads on SCSI drives?
On Thu, Apr 21, 2005 at 10:44:23AM -0500, Drew Winstel wrote: It has been a busy week, I know, but does anyone have any tips? You could try setting read cache disable, I don't know if that setting must be honored, or how ATA/SATA handle it. See mode page 8 for SCSI block commands. The sg utilities sg_modes can probably set it. Better yet, do IO to more locations on the disk, not just the very beginning and the very end. The reads we're calling are getting cached. If we call 100 reads--50 to the beginning of the drive alternating with 50 to the end--the first read will sometimes appear to have a realistic result, then the rest will all complete in the neighborhood of 10 microseconds. -- Patrick Mansfield - 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: [dm-devel] Re: fastfail operation and retries
On Fri, Apr 22, 2005 at 12:52:56AM +0200, Lars Marowsky-Bree wrote: On 2005-04-21T15:13:16, Patrick Mansfield [EMAIL PROTECTED] wrote: The most recent udm patchset has a patch by Jens Axboe and myself to pass up sense data / error codes in the bio so the dm mpath module can deal with it. But the scmd-result is not passed back. Bear with me and my limitted knowledge of the SCSI midlayer for a second: What additional benefit would this provide over sense key/asc/ascq the error parameter in the bio end_io path? So we can mark a path in dm as failed or not; then dm won't mark a path failed for driver, transport, or other retryable errors. As noted, this might not lead to user visible affects, since retryable errors _should_ end up failing and then re-enabling the path, but that could lead to problems. But the code paths will be cleaner. Better to decode the error once, and then pass that data back to the blk layer. Decoding is device specific. So is the handling of path initialization and others. I'd rather have this consolidated in one module, than have parts of it in the mid-layer and other parts in the multipath code. Me too, but I'm arguing to decode them in scsi core. Could this be handled by a module in the mid-layer which receives commands from the DM multipath layers above, and pass appropriate flags back up? Probably. (I think this is what you're suggesting.) But frankly, I prefer the current approach, which works. I don't see a real benefit in your architecture, besides spreading things out further. scsi core (I don't like calling it midlayer) could have a module or such. The same decoding that is being put into dm hardware modules should also be in scsi core. That is, when running such hardware without dm multipath (single pathed or just stupidly) we still want the decoding of the sense data, especially for retryable errors. The one thing which could be improved here is that I'm not sure if an EIO w/o sense data from the SCSI mid-layer always corresponds to a timeout. Could we get EIO also for other errors? You should be getting EIO for all IO failures, timeout or not. For example a cable pull returns DID_NO_CONNECT (for at least qlogic, and maybe for emulex), its decoded in scsi_decide_disposition, and scsi core calls scsi_end_request(x, 0, x, x), and then calls end_that_request_chunk(x, 0, x) and that sets error to EIO. However, as you correctly state later, it's pretty safe to treat such errors as a path error and retry elsewhere, because if it was a false failure, the path checker will reinstate soonish. timeout could be a failure anywhere, in the transport or because of target/media/LUN problems. Or not a real error at all, just a busy device or too short a timeout setting. Well, the not real errors might benefit from the IO being retried on another path though. Yes. Does path checker take paths permanently offline after multiple failures? The path checker lives in user-space, and that's policy ;-) So, from the kernel perspective, it doesn't matter. User-space currently does not 'permanently' fail paths, but it could be modified to do so if it goes up/down at a too high rate, basically dampening for stability. Patches welcome. So though I don't like the approach: distinguishing timeouts or ensuring that path checker won't continually reenable a path might be good enough, as long as there are no other error cases (driver or SCSI) that could lead to long lasting failures. That's essentially what is being done. However, there's some more special cases (like a storage array telling us that that service processor is no longer active and we should switch not to another path on the same, but to the other SP; which we model in dm-mpath via different priority groups and causing a PG switch), and some errors translate to errors being immediately propagated upwards (media error, illegal request, data protect and some others; again, this might include specific handling based on the storage being addressed), because for these retrying on another path (or switching service processors) doesn't make any sense or might be even harmful. Yes ... I'm familiar with such hardware. Yes, but that doesn't mean we should decode SCSI sense or scsi core error errors (i.e. scmd-result) in dm space. This happens in the SCSI layer; dm-mpath only sees already 'decoded' sense key/asc/ascq. But that data is not decoded, dm has to look at the sense value etc. Some of that must overlap with the code in scsi core. Also, non-scsi drivers would like to use dm multipath, like DASD. Using extended blk errors allows simpler support for such devices and drivers. Sure. The bi_error field introduced by Axboe's patch has flags detailing what kind of error information is available - it's either ERRNO (basically, the current error), SENSE (for certain scsi requests, where sense is available), and could be extended
Re: proc_name in sysfs
On Thu, Apr 07, 2005 at 11:06:03AM +1000, Douglas Gilbert wrote: Patrick Mansfield wrote: On Wed, Apr 06, 2005 at 01:40:04PM +0200, Frederic TEMPORELLI wrote: 2/ now, how can we get the adapter module name from sysfs ? Why do you need it? Patrick, lsscsi currently uses proc_name so it needs to be changed to use the above logic (if LLDs are going to stop populating proc_name). Oops, I didn't notice, I had assumed it was using the sysfs layout. Yes, seems like it should use the sysfs driver info, proc_name is rather useless in sysfs context. It has been suggested that I extend lsscsi to show transport info (as seen from the HBA) found in the various *_transport directories in sysfs. As an option that sounds nice. Also I have been thinking about ways to list less tha all scsi devices. For example: lsscsi 1:0:3:0 to look at one device and lsscsi 1:- for all scsi devices hanging off host1. I'm not sure whether lsscsi /dev/sda is a good idea. Any suggestions? Sounds good, but maybe not (directly) for /dev. udevinfo can supply that, it has a /dev to /sys mapping: [elm3b79 patman]$ udevinfo -q path -n /udev/mydisk-sdag /block/sdm -- Patrick Mansfield - 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: proc_name in sysfs
On Thu, Apr 07, 2005 at 08:35:16AM +0200, Frederic TEMPORELLI wrote: Hi, Sorry, no such driver directory in /sys/class/scsi_host/hostX/ Doug answered that. Why do you need it? If you answer the above you might get better/other suggestions. -- Patrick Mansfield - 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: proc_name in sysfs
On Wed, Apr 06, 2005 at 01:40:04PM +0200, Frederic TEMPORELLI wrote:
2/ now, how can we get the adapter module name from sysfs ?
Why do you need it?
Anyway, try lsscsi, it walks the sysfs tree:
[elm3b79 patman]$ lsscsi -H
[0]qla1280
[1]qla1280
[2]qla2xxx
[3]qla2xxx
Or, script it:
[elm3b79 tmp]$ more xx.sh
#! /bin/sh
hdir=/sys/class/scsi_host
for i in ${hdir}/host*
do
host_dir=$(cd ${i}/device;/bin/pwd)
driver_dir=$(cd ${host_dir}/../driver;/bin/pwd)
module=$(basename ${driver_dir})
# echo ${i} is in: ${host_dir}
echo ${i} module (driver) is: ${module}
done
[elm3b79 tmp]$ sh ./xx.sh
/sys/class/scsi_host/host0 module (driver) is: qla1280
/sys/class/scsi_host/host1 module (driver) is: qla1280
/sys/class/scsi_host/host2 module (driver) is: qla2300
/sys/class/scsi_host/host3 module (driver) is: qla2300
-- Patrick Mansfield
-
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 Use bus dev_attrs to create scsi_device attributes
On Wed, Mar 30, 2005 at 08:32:44PM +0200, Kay Sievers wrote:
On Thu, 2005-03-17 at 09:53 -0500, James Bottomley wrote:
On Wed, 2005-03-16 at 14:45 -0800, Patrick Mansfield wrote:
Any comments on this? Should I resend these patches?
Well, the basic comment is that there are a lot of features that SCSI
has that the driver core lacks:
1) Attribute overrides. This is actually part of the published API for SCSI
What does this exactly mean? Handle the same attribute dynamically with
a different source of data?
Well a different function handled by the host driver, rather than the
function in scsi core, for example, the twa_queue_depth_attr in
drivers/scsi/3w-9xxx.c overrides the simple read attr function in
scsi_syfs.c created via this line:
sdev_rd_attr (queue_depth, %d\n).
The patch left this in but only for queue_depth, not for all of the
scsi_devie attributes. We have sht-change_queue_depth that can already
handle this, some drivers use it, but some still use the sdev_attrs to
override the queue_depth. IMO, we should get rid of the override, James
doesn't agree.
James - are you OK with allowing only specific overrides of attributes?
2) Ability to add extra attributes---several drivers use this
What is missing in the driver core here? Why can't you add/remove
attribute files at any time?
The patch left this alone, but should be changed to make sure duplicate
(that we can't override) attributes get errors. It is just a nice way for
host adapters to add attributes to a scsi_device.
But, for any of these non bus_attr and class attributes, the hotplug
notification (for scsi_device or the upper level block/char device) will
still come before the attributes are created. This is also true for the
transport attributes. This is a potential problem, I know of no udev
program or hotplug helpers that use any of these attributes.
I see no easy way around this problem without a multi-step registration,
like a device_init(), device_ready(). So a device_add would just be:
device_init()
device_ready()
Is your kobject_hotplug patch still pending?
We also need the following, else dev_attrs will show up after the probe
and hotplug event for a matching driver (for example, an sd block hotplug
event is generated via the device_attach() call). This could be causing
problems today, AFAIR you already hack around this problem in udev.
--- bleed-2.5/drivers/base/orig-bus.c Tue Mar 15 17:08:18 2005
+++ bleed-2.5/drivers/base/bus.cWed Mar 30 10:48:34 2005
@@ -458,14 +458,14 @@ int bus_add_device(struct device * dev)
int error = 0;
if (bus) {
+ device_add_attrs(bus, dev);
+ sysfs_create_link(bus-devices.kobj, dev-kobj, dev-bus_id);
+ sysfs_create_link(dev-kobj, dev-bus-subsys.kset.kobj,
bus);
down_write(dev-bus-subsys.rwsem);
pr_debug(bus %s: add device %s\n, bus-name, dev-bus_id);
list_add_tail(dev-bus_list, dev-bus-devices.list);
device_attach(dev);
up_write(dev-bus-subsys.rwsem);
- device_add_attrs(bus, dev);
- sysfs_create_link(bus-devices.kobj, dev-kobj, dev-bus_id);
- sysfs_create_link(dev-kobj, dev-bus-subsys.kset.kobj,
bus);
}
return error;
}
-- Patrick Mansfield
-
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 Use bus dev_attrs to create scsi_device attributes
On Wed, Mar 02, 2005 at 11:46:47AM -0800, Patrick Mansfield wrote:
Use bus dev_attrs to create the default scsi_device attributes.
Note sdev_default_attrs is not a pointer to an array (like
scsi_sysfs_sdev_attrs), and so DEVICE_ATTR's can be removed, and __ATTR
used instaed.
Any comments on this? Should I resend these patches?
Do we need a new driver interface that allows the driver to explicitly
send the hotplug after all attributes have been created?
Such a new interface would allow scsi to continue to create attributes
(based on the underlying HBA or transport capability) that are sometimes
read only, and sometimes read+write. The current driver interface does not
allow default attributes to have different read/write properties.
And scsi could keep its current host override ability (we can't use the
current override code with the default attributes).
In any case, we need changes so udev can stop waiting for sysfs attributes.
Signed-off-by: Patrick Mansfield [EMAIL PROTECTED]
--- sattrs-linux-2.6.11/drivers/scsi/s1-scsi_sysfs.c 2005-03-02
09:58:21.0 -0800
+++ sattrs-linux-2.6.11/drivers/scsi/scsi_sysfs.c 2005-03-02
10:22:25.0 -0800
@@ -193,40 +193,6 @@
.release= scsi_device_cls_release,
};
-/* all probing is done in the individual -probe routines */
-static int scsi_bus_match(struct device *dev, struct device_driver *gendrv)
-{
- struct scsi_device *sdp = to_scsi_device(dev);
- if (sdp-no_uld_attach)
- return 0;
- return (sdp-inq_periph_qual == SCSI_INQ_PQ_CON)? 1: 0;
-}
-
-struct bus_type scsi_bus_type = {
-.name= scsi,
-.match = scsi_bus_match,
-};
-
-int scsi_sysfs_register(void)
-{
- int error;
-
- error = bus_register(scsi_bus_type);
- if (!error) {
- error = class_register(sdev_class);
- if (error)
- bus_unregister(scsi_bus_type);
- }
-
- return error;
-}
-
-void scsi_sysfs_unregister(void)
-{
- class_unregister(sdev_class);
- bus_unregister(scsi_bus_type);
-}
-
/*
* sdev_show_function: macro to create an attr function that can be used to
* show a non-bit field.
@@ -245,8 +211,7 @@
* read only field.
*/
#define sdev_rd_attr(field, format_string) \
- sdev_show_function(field, format_string)\
-static DEVICE_ATTR(field, S_IRUGO, sdev_show_##field, NULL);
+ sdev_show_function(field, format_string)
/*
@@ -263,8 +228,7 @@
sdev = to_scsi_device(dev); \
snscanf (buf, 20, format_string, sdev-field); \
return count; \
-}\
-static DEVICE_ATTR(field, S_IRUGO | S_IWUSR, sdev_show_##field,
sdev_store_##field);
+}
/* Currently we don't export bit fields, but we might in future,
* so leave this code in */
@@ -288,8 +252,7 @@
ret = count;\
} \
return ret; \
-}\
-static DEVICE_ATTR(field, S_IRUGO | S_IWUSR, sdev_show_##field,
sdev_store_##field);
+}
/*
* scsi_sdev_check_buf_bit: return 0 if buf is 0, return 1 if buf is 1,
@@ -336,15 +299,13 @@
sdev-timeout = timeout * HZ;
return count;
}
-static DEVICE_ATTR(timeout, S_IRUGO | S_IWUSR, sdev_show_timeout,
sdev_store_timeout);
static ssize_t
-store_rescan_field (struct device *dev, const char *buf, size_t count)
+sdev_store_rescan (struct device *dev, const char *buf, size_t count)
{
scsi_rescan_device(dev);
return count;
}
-static DEVICE_ATTR(rescan, S_IWUSR, NULL, store_rescan_field);
static ssize_t sdev_store_delete(struct device *dev, const char *buf,
size_t count)
@@ -352,10 +313,9 @@
scsi_remove_device(to_scsi_device(dev));
return count;
};
-static DEVICE_ATTR(delete, S_IWUSR, NULL, sdev_store_delete);
static ssize_t
-store_state_field(struct device *dev, const char *buf, size_t count)
+sdev_store_state(struct device *dev, const char *buf, size_t count)
{
int i;
struct scsi_device *sdev = to_scsi_device(dev);
@@ -378,7 +338,7 @@
}
static ssize_t
-show_state_field(struct device *dev, char *buf)
+sdev_show_state(struct device *dev, char *buf)
{
struct scsi_device *sdev = to_scsi_device(dev);
const char *name = scsi_device_state_name(sdev-sdev_state);
@@ -389,8 +349,6 @@
return snprintf(buf, 20, %s\n, name);
}
-static DEVICE_ATTR(state, S_IRUGO | S_IWUSR, show_state_field,
store_state_field);
-
sdev_show_function
[PATCH] 0/2 use sysfs bus dev_attrs for scsi_device attributes
A couple patches so that when pending changes to sysfs/hotplug are made, patches discussed here: http://marc.theaimsgroup.com/?t=11093974272r=1w=2 We will get the hotplug event for a scsi_device only after all the default scsi_device attributes are created. The removal of the attr_changed_internally() was done so queue_type can more easily be used as a default attribute (using the bus dev_attrs, there is no way for some devices to create it read only, and for others to create it as read write). Tested with qla2300 and qla1280 drivers - neither currently support writable queue_depth or queue_type. The attr_overridden (and post these patches, scsi_sysfs_sdev_attrs) should someday be removed, the only attribute being overridden (versus a host specific scsi_device attribute) today is queue_depth, and we have shost-change_queue_depth that can be used instead. -- Patrick Mansfield - 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] 1/2 remove attr_changed_internally
Get rid of the attr_changed_internally(), and always create queue_type and
queue_depth as read/write, and then writes fail if not supported.
Signed-off-by: Patrick Mansfield [EMAIL PROTECTED]
--- linux-2.6.11/drivers/scsi/scsi_sysfs.c 2005-03-02 02:59:50.0
-0800
+++ sattrs-linux-2.6.11/drivers/scsi/scsi_sysfs.c 2005-03-02
09:27:15.0 -0800
@@ -312,7 +312,6 @@
* Create the actual show/store functions and data structures.
*/
sdev_rd_attr (device_blocked, %d\n);
-sdev_rd_attr (queue_depth, %d\n);
sdev_rd_attr (type, %d\n);
sdev_rd_attr (scsi_level, %d\n);
sdev_rd_attr (vendor, %.8s\n);
@@ -392,41 +391,9 @@
static DEVICE_ATTR(state, S_IRUGO | S_IWUSR, show_state_field,
store_state_field);
-static ssize_t
-show_queue_type_field(struct device *dev, char *buf)
-{
- struct scsi_device *sdev = to_scsi_device(dev);
- const char *name = none;
-
- if (sdev-ordered_tags)
- name = ordered;
- else if (sdev-simple_tags)
- name = simple;
-
- return snprintf(buf, 20, %s\n, name);
-}
-
-static DEVICE_ATTR(queue_type, S_IRUGO, show_queue_type_field, NULL);
-
-
-/* Default template for device attributes. May NOT be modified */
-static struct device_attribute *scsi_sysfs_sdev_attrs[] = {
- dev_attr_device_blocked,
- dev_attr_queue_depth,
- dev_attr_queue_type,
- dev_attr_type,
- dev_attr_scsi_level,
- dev_attr_vendor,
- dev_attr_model,
- dev_attr_rev,
- dev_attr_rescan,
- dev_attr_delete,
- dev_attr_state,
- dev_attr_timeout,
- NULL
-};
+sdev_show_function (queue_depth, %d\n);
-static ssize_t sdev_store_queue_depth_rw(struct device *dev, const char *buf,
+static ssize_t sdev_store_queue_depth(struct device *dev, const char *buf,
size_t count)
{
int depth, retval;
@@ -448,11 +415,25 @@
return count;
}
-static struct device_attribute sdev_attr_queue_depth_rw =
+static struct device_attribute dev_attr_queue_depth =
__ATTR(queue_depth, S_IRUGO | S_IWUSR, sdev_show_queue_depth,
- sdev_store_queue_depth_rw);
+ sdev_store_queue_depth);
-static ssize_t sdev_store_queue_type_rw(struct device *dev, const char *buf,
+static ssize_t
+show_queue_type_field(struct device *dev, char *buf)
+{
+ struct scsi_device *sdev = to_scsi_device(dev);
+ const char *name = none;
+
+ if (sdev-ordered_tags)
+ name = ordered;
+ else if (sdev-simple_tags)
+ name = simple;
+
+ return snprintf(buf, 20, %s\n, name);
+}
+
+static ssize_t sdev_store_queue_type(struct device *dev, const char *buf,
size_t count)
{
struct scsi_device *sdev = to_scsi_device(dev);
@@ -480,23 +461,26 @@
return count;
}
-static struct device_attribute sdev_attr_queue_type_rw =
+static struct device_attribute dev_attr_queue_type =
__ATTR(queue_type, S_IRUGO | S_IWUSR, show_queue_type_field,
- sdev_store_queue_type_rw);
-
-static struct device_attribute *attr_changed_internally(
- struct Scsi_Host *shost,
- struct device_attribute * attr)
-{
- if (!strcmp(queue_depth, attr-attr.name)
-shost-hostt-change_queue_depth)
- return sdev_attr_queue_depth_rw;
- else if (!strcmp(queue_type, attr-attr.name)
-shost-hostt-change_queue_type)
- return sdev_attr_queue_type_rw;
- return attr;
-}
+ sdev_store_queue_type);
+/* Default template for device attributes. May NOT be modified */
+static struct device_attribute *scsi_sysfs_sdev_attrs[] = {
+ dev_attr_device_blocked,
+ dev_attr_queue_depth,
+ dev_attr_queue_type,
+ dev_attr_type,
+ dev_attr_scsi_level,
+ dev_attr_vendor,
+ dev_attr_model,
+ dev_attr_rev,
+ dev_attr_rescan,
+ dev_attr_delete,
+ dev_attr_state,
+ dev_attr_timeout,
+ NULL
+};
static struct device_attribute *attr_overridden(
struct device_attribute **attrs,
@@ -602,10 +586,8 @@
for (i = 0; scsi_sysfs_sdev_attrs[i]; i++) {
if (!attr_overridden(sdev-host-hostt-sdev_attrs,
scsi_sysfs_sdev_attrs[i])) {
- struct device_attribute * attr =
- attr_changed_internally(sdev-host,
-
scsi_sysfs_sdev_attrs[i]);
- error = device_create_file(sdev-sdev_gendev, attr);
+ error = device_create_file(sdev-sdev_gendev,
+ scsi_sysfs_sdev_attrs[i]);
if (error) {
scsi_remove_device(sdev);
goto out;
-
To unsubscribe from this list: send the line
[PATCH] 2/2 Use bus dev_attrs to create scsi_device attributes
Use bus dev_attrs to create the default scsi_device attributes.
Note sdev_default_attrs is not a pointer to an array (like
scsi_sysfs_sdev_attrs), and so DEVICE_ATTR's can be removed, and __ATTR
used instaed.
Signed-off-by: Patrick Mansfield [EMAIL PROTECTED]
--- sattrs-linux-2.6.11/drivers/scsi/s1-scsi_sysfs.c2005-03-02
09:58:21.0 -0800
+++ sattrs-linux-2.6.11/drivers/scsi/scsi_sysfs.c 2005-03-02
10:22:25.0 -0800
@@ -193,40 +193,6 @@
.release= scsi_device_cls_release,
};
-/* all probing is done in the individual -probe routines */
-static int scsi_bus_match(struct device *dev, struct device_driver *gendrv)
-{
- struct scsi_device *sdp = to_scsi_device(dev);
- if (sdp-no_uld_attach)
- return 0;
- return (sdp-inq_periph_qual == SCSI_INQ_PQ_CON)? 1: 0;
-}
-
-struct bus_type scsi_bus_type = {
-.name = scsi,
-.match = scsi_bus_match,
-};
-
-int scsi_sysfs_register(void)
-{
- int error;
-
- error = bus_register(scsi_bus_type);
- if (!error) {
- error = class_register(sdev_class);
- if (error)
- bus_unregister(scsi_bus_type);
- }
-
- return error;
-}
-
-void scsi_sysfs_unregister(void)
-{
- class_unregister(sdev_class);
- bus_unregister(scsi_bus_type);
-}
-
/*
* sdev_show_function: macro to create an attr function that can be used to
* show a non-bit field.
@@ -245,8 +211,7 @@
* read only field.
*/
#define sdev_rd_attr(field, format_string) \
- sdev_show_function(field, format_string)\
-static DEVICE_ATTR(field, S_IRUGO, sdev_show_##field, NULL);
+ sdev_show_function(field, format_string)
/*
@@ -263,8 +228,7 @@
sdev = to_scsi_device(dev); \
snscanf (buf, 20, format_string, sdev-field); \
return count; \
-} \
-static DEVICE_ATTR(field, S_IRUGO | S_IWUSR, sdev_show_##field,
sdev_store_##field);
+}
/* Currently we don't export bit fields, but we might in future,
* so leave this code in */
@@ -288,8 +252,7 @@
ret = count;\
} \
return ret; \
-} \
-static DEVICE_ATTR(field, S_IRUGO | S_IWUSR, sdev_show_##field,
sdev_store_##field);
+}
/*
* scsi_sdev_check_buf_bit: return 0 if buf is 0, return 1 if buf is 1,
@@ -336,15 +299,13 @@
sdev-timeout = timeout * HZ;
return count;
}
-static DEVICE_ATTR(timeout, S_IRUGO | S_IWUSR, sdev_show_timeout,
sdev_store_timeout);
static ssize_t
-store_rescan_field (struct device *dev, const char *buf, size_t count)
+sdev_store_rescan (struct device *dev, const char *buf, size_t count)
{
scsi_rescan_device(dev);
return count;
}
-static DEVICE_ATTR(rescan, S_IWUSR, NULL, store_rescan_field);
static ssize_t sdev_store_delete(struct device *dev, const char *buf,
size_t count)
@@ -352,10 +313,9 @@
scsi_remove_device(to_scsi_device(dev));
return count;
};
-static DEVICE_ATTR(delete, S_IWUSR, NULL, sdev_store_delete);
static ssize_t
-store_state_field(struct device *dev, const char *buf, size_t count)
+sdev_store_state(struct device *dev, const char *buf, size_t count)
{
int i;
struct scsi_device *sdev = to_scsi_device(dev);
@@ -378,7 +338,7 @@
}
static ssize_t
-show_state_field(struct device *dev, char *buf)
+sdev_show_state(struct device *dev, char *buf)
{
struct scsi_device *sdev = to_scsi_device(dev);
const char *name = scsi_device_state_name(sdev-sdev_state);
@@ -389,8 +349,6 @@
return snprintf(buf, 20, %s\n, name);
}
-static DEVICE_ATTR(state, S_IRUGO | S_IWUSR, show_state_field,
store_state_field);
-
sdev_show_function (queue_depth, %d\n);
static ssize_t sdev_store_queue_depth(struct device *dev, const char *buf,
@@ -420,7 +378,7 @@
sdev_store_queue_depth);
static ssize_t
-show_queue_type_field(struct device *dev, char *buf)
+sdev_show_queue_type(struct device *dev, char *buf)
{
struct scsi_device *sdev = to_scsi_device(dev);
const char *name = none;
@@ -461,25 +419,29 @@
return count;
}
-static struct device_attribute dev_attr_queue_type =
- __ATTR(queue_type, S_IRUGO | S_IWUSR, show_queue_type_field,
- sdev_store_queue_type);
+#define SDEV_ATTR_RO(_name) __ATTR(_name, S_IRUGO, sdev_show_##_name, NULL)
+#define SDEV_ATTR_WO(_name) __ATTR(_name, S_IWUSR, NULL, sdev_store_##_name)
+#define SDEV_ATTR_RW(_name) __ATTR(_name, S_IRUGO
Re: [PATCH as470] Add a NOREPORTLUN blacklist flag
On Sun, Feb 20, 2005 at 10:47:09PM -0800, Matthew Dharm wrote: On Sun, Feb 20, 2005 at 10:44:21PM -0500, Alan Stern wrote: Matt, it looks like the best way to solve this problem is to go back to the old strategy of always setting the SCSI revision to 2 (no matter what it might actually be), at least for Direct Access devices. That would suppress the REPORT_LUNS command. Would we lose anything by doing this? Besides the use of REPORT_LUNS on devices which actually support it? I don't think so... It would only matter if the device had sparse luns (multiple luns/disks that are not consecutively numbered). You can always dynamically add it to the black list to force REPORT LUN usage (for SCSI_2 devices) via BLIST_REPORTLUN2, and if it did not support REPORT LUNS add it as sparse lun via BLIST_SPARSELUN. Samuel or other owners of the hardware: did you check for firmware updates? You should make sure the hardware vendor at least knows about the problem. The bridge hardware (USB/firewire to ide) should probably mark it as SCSI 2, and it should be fixed to handle and fail the REPORT LUN in a sane way. I wonder if printing a warning if sdev-scsi_level SCSI_2 would be useful... Probably not. -- Patrick Mansfield - 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: [ANNOUNCE] hotplug-ng 001 release
[added linux-scsi] On Wed, Feb 16, 2005 at 11:32:51PM +, Willem Riede wrote: On 02/16/2005 06:17:41 PM, Roman Kagan wrote: I tried out Roman's patch, well at least simple loading of st via modprobe scsi-type-1, works nicely as expected. (modprobe -r sd is hanging on down() in device_unregister with 2.6.11-rc4 ... must be a ref count problem, have not figured anything out, and took me a while before trying st and sg instead.) On Wed, Feb 16, 2005 at 11:02:41PM +, Willem Riede wrote: On 02/16/2005 06:07:52 AM, Roman Kagan wrote: It handles only st, sd_mod and sr_mod cases (as hotplug-ng-001/module_scsi.c did). Are there any other? Not all tapes are supported by st - OnStream drives need osst instead. As an excuse I can say that I reproduced what was in hotplug-ng-001/module_scsi.c, no more, no less :) How do you suggest that is to be handled? AFAICS they coexist nicely, so, if you add the same thing to osst.c: MODULE_ALIAS(scsi-type-1);/* TYPE_TAPE */ both osst and st will be loaded (provided Greg convinces Rusty to make modprobe load _all_ matching modules as he suggested the other day). Then the one whose .probe succeeds will handle the device. Will that work? Yes. If we can get that load-all behaviour implemented, everything will be fine. You could also append the sdev-vendor and sdev-model, and use alias wild cards. So OSST would not be loaded for all tape devices found (not a big deal). st would still load for all tapes (likely the same as we have today, and not easy to *not* load it for osst devices). That is, add aliases to osst.c like: MODULE_ALIAS(scsi-type-1-onStream-SC-*); MODULE_ALIAS(scsi-type-1-onStream-DI-*); etc. The vendor (8 bytes) and model (16 bytes) can have spaces, and the values are not '\0' terminated. modprobe does not seem to handle spaces in an alias. And for st.c: MODULE_ALIAS(scsi-type-1-*); sd.c: MODULE_ALIAS(scsi-type-4-*); MODULE_ALIAS(scsi-type-5-*); Also, sg loading would want (along with modprobe load all feature): MODULE_ALIAS(scsi-type-*); -- Patrick Mansfield - 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: [ANNOUNCE] hotplug-ng 001 release
On Fri, Feb 18, 2005 at 10:41:35PM +0300, Roman Kagan wrote: On Fri, Feb 18, 2005 at 10:33:50AM -0800, Patrick Mansfield wrote: The block SG_IO handles the ioctls, but not devices without a SCSI upper level driver (i.e. not tape, disk or cdrom). Then it might make sense to explicitly list in sg.c the TYPE_* not matched by s[dtr]. sg can be used even if another scsi upper level driver is loaded. fedora core tried something like that for a while, I'm not sure what happened (besides it being really hard to do), and haven't noticed anything different in recent (2.6.x) fc kernels. So these drivers can compete for the same device? Are there deterministic rules on which one is supposed to win? And is there a userspace interface to unbind one driver and bind another? Otherwise it may mean that automatic module loading is inappropriate here at all... No to all. It is OK to autoload sg, it has special handling. Even though greg probably hates it, it is much better than a /proc/bus/scsi ;-) -- Patrick Mansfield - 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: scsi disk registration - double messages
On Tue, Feb 15, 2005 at 02:33:35PM +, Matthew Wilcox wrote:
On Tue, Feb 15, 2005 at 12:01:11PM +0200, Meelis Roos wrote:
The messages about registration of sda appear tiwice for some reason. This
is only cosmetic but still a little strange:
Yes, that happens for everyone.
I posted before but no replies:
Al's log for the patch says Work around devices with bogus media change
indication on the first open.
What bogus device? Why not put the change in the driver or black list
the device, rather than doing so for all block devices?
This worked fine for me, but I might break with the bogus media:
diff -uprN -X /home/patman/dontdiff linux-2.6.11-rc1/fs/partitions/check.c
no-double-sd-linux-2.6.11-rc1/fs/partitions/check.c
--- linux-2.6.11-rc1/fs/partitions/check.c Fri Dec 24 13:35:28 2004
+++ no-double-sd-linux-2.6.11-rc1/fs/partitions/check.c Fri Jan 21 11:19:00 2005
@@ -375,8 +375,6 @@ int rescan_partitions(struct gendisk *di
bdev-bd_invalidated = 0;
for (p = 1; p disk-minors; p++)
delete_partition(disk, p);
- if (disk-fops-revalidate_disk)
- disk-fops-revalidate_disk(disk);
if (!get_capacity(disk) || !(state = check_partition(disk, bdev)))
return 0;
for (p = 1; p state-limit; p++) {
-- Patrick Mansfield
-
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: [usb-storage] Re: MPIO HS200 Gigabox weird behaviour again
On Fri, Feb 11, 2005 at 01:31:30PM -0500, Alan Stern wrote: On Fri, 11 Feb 2005, James Bottomley wrote: On Fri, 2005-02-11 at 11:00 -0500, Alan Stern wrote: SCSI developers: Is there any hope of this? Well, IBM also has some old buggy piece of hardware that apparently gives fatal errors but actually wants them retried: http://marc.theaimsgroup.com/?t=11008869615 After a bit of argument, they agreed to do it as a blacklist flag, so you should be able to add the same flag to your gigabox. I planned to put the patch in just as soon as they managed to send the patch unmangled by a mailer, but they went very quiet. Thanks, James. Radovan: Below is an updated version of the patch James mentioned, with an entry included for your Gigabox drive. It's meant to apply to 2.6.11-rc3-bk5, but it will probably go with older kernels too. Try it out and let me know how it works. If it solves your problem, I'll submit it for inclusion in the official kernel. Do you have the asc/ascq for the USB device? Longer term, it would be nice to have a black list modifiable via sysfs (similiar to the scsi devinfo one) with a vendor + model + sense key + asc + ascq, for both this USB device and for the IBM one. AFAIUI, the IBM ESS/2105 really wants certain hardware errors retried not all of them, I don't know if the IBM ESS/storage developers were OK with Martin's patch (I never see responses from them to anything posted on linux-scsi). The sense black list could be used for quirks plus vendor specific asc/ascq values. It could also be used by dm multipath, if error codes (like Mike C's old patch) and not sense data were passed up. James - would you be OK with such an approach? It should be populated after loading scsi_mod, but before loading HBA drivers (the same is true for devinfo); I think this means manually loading scsi_mod, populate the tables, then allow hotplug loading of HBA drivers. We still need a nice way to display and modify a list or array in sysfs (for both the devinfo or this asc/ascq table). -- Patrick Mansfield - 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: still BUG's for smp_processor_id() on interrupt
On Tue, Feb 08, 2005 at 10:44:35PM -0800, Andrew Vasquez wrote: On Tue, 08 Feb 2005, Patrick Mansfield wrote: I'm still getting lots of BUG's for the smp_processor_id, but via the interrupt function. It's during the driver's init-time polling for interrupts... Argg -- that was careless... Again, the smp_processor_id() is used only as a heuristic. The attached patch should quash the noise. OK, that gets rid of the BUG stuff, but now I am hitting an oops. A bit odd that the smp_processor_id() debug code seemed to prevent this. I am using an old compiler on a NUMAQ system. Attaching the .config. This is with 2.6 bk from yesterday + your patch. It looks like it is in the list_add_tail() at the end of attribute_container_add_device. [elm3b79 base]$ gcc -v Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs gcc version 2.95.4 20011002 (Debian prerelease) Unable to handle kernel paging request at virtual address 42555300 printing eip: c01dbebb *pde = 084bac0f Oops: [#1] PREEMPT SMP Modules linked in: qla2300 qla2xxx scsi_transport_fc CPU:5 EIP:0060:[c01dbebb]Not tainted VLI EFLAGS: 00010202 (2.6.11-rc3pm) EIP is at attribute_container_add_device+0x143/0x16c eax: 42555300 ebx: f46200e4 ecx: edx: 42555300 esi: c0357964 edi: f462 ebp: c0357964 esp: e0b92e50 ds: 007b es: 007b ss: 0068 Process modprobe (pid: 8582, threadinfo=e0b92000 task=f4880570) Stack: f46200e4 c0357964 f462 c0357964 f462013c 42555300 c01dc2c7 f46200e4 c01dc294 c0203658 f46200e4 f4620184 f462 f46200e4 c01fbf79 f462 f46201ec f462 f5a81444 036310e5 f88b79d7 f462 f5a81444 Call Trace: [c01dc2c7] transport_setup_device+0xf/0x14 [c01dc294] transport_setup_classdev+0x0/0x24 [c0203658] scsi_sysfs_add_host+0xac/0xbc [c01fbf79] scsi_add_host+0xf1/0x124 [f88b79d7] qla2x00_probe_one+0x75b/0x874 [qla2xxx] [f88d0012] gcc2_compiled.+0x12/0x18 [qla2300] [c01b2424] pci_device_probe_static+0x2c/0x40 [c01b2457] __pci_device_probe+0x1f/0x34 [c01b2488] pci_device_probe+0x1c/0x34 [c01d918d] driver_probe_device+0x41/0x64 [c01d9260] driver_attach+0x34/0x68 [c01d96bb] bus_add_driver+0x8b/0xbc [c01d9c08] driver_register+0x50/0x54 [c01b2686] pci_register_driver+0x86/0xa0 [f00a] qla2300_init+0xa/0x10 [qla2300] [c012c479] sys_init_module+0x111/0x270 [c0102443] syscall_call+0x7/0xb Code: 55 e8 4a 02 00 00 83 c4 04 8b 44 24 14 83 c0 08 8b 50 04 89 58 04 89 03 89 53 04 89 1a 8b 44 24 14 8b 00 89 44 24 14 8b 54 24 14 8b 02 0f 18 00 90 81 fa 80 91 46 c0 0f 85 e7 fe ff ff f0 ff 05 -- Patrick Mansfield # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11-rc3 # Wed Feb 9 09:00:49 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # CONFIG_CLEAN_COMPILE is not set CONFIG_BROKEN=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y # # General setup # CONFIG_LOCALVERSION=pm CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_LOG_BUF_SHIFT=16 CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_FUTEX=y CONFIG_EPOLL=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Processor type and features # # CONFIG_X86_PC is not set # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set CONFIG_X86_NUMAQ=y # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set CONFIG_MPENTIUMIII=y # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y
Re: still BUG's for smp_processor_id() on interrupt
On Wed, Feb 09, 2005 at 01:13:44PM -0500, [EMAIL PROTECTED] wrote: This looks suspiciously like the oops trace that I saw when loading/unloading driver a couple of times. Make sure you have the following patches. http://marc.theaimsgroup.com/?l=linux-scsim=110729104720492w=2 http://marc.theaimsgroup.com/?l=linux-scsim=110737816906830w=2 Thanks James - Yes, it was a driver reload (after applying Andrew V's patch, rmmod qla2300 and then insmod qla2300). I had found the second patch fix the fix for multiple HBA problem with transport and verified it is in mainline. But missed the first one fix HBA removal problem with transport classes, plus it is NOT in mainline. I applied and no more oops (and no BUGs using _smp_processor_id()). -- Patrick Mansfield - 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
still BUG's for smp_processor_id() on interrupt
Hi Andrew - I'm still getting lots of BUG's for the smp_processor_id, but via the interrupt function. I am running the latest bk, it has your patch to qla_os.c: [elm3b79 qla2xxx]$ grep smp_proc qla_os.c if (_smp_processor_id() == ha-last_irq_cpu || was_empty) I'm running on a NUMAQ (sometimes has funky latencies). There are no errors for simple IO (dd if=/dev/sda of=/dev/null bs=64k). There are about 40 disk drives attached. More information available on request ... elm3b79.beaverton.ibm.com login: QLogic Fibre Channel HBA Driver qla2300 :01:0c.0: Found an ISP2300, irq 40, iobase 0xf888a000 qla2300 :01:0c.0: Configuring PCI space... qla2300 :01:0c.0: Configure NVRAM parameters... qla2300 :01:0c.0: Verifying loaded RISC code... BUG: using smp_processor_id() in preemptible [0001] code: modprobe/1362 caller is qla2300_intr_handler+0x184/0x204 [qla2xxx] [c01aea79] smp_processor_id+0x99/0xb8 [f88c0294] qla2300_intr_handler+0x184/0x204 [qla2xxx] [f88be39a] qla2x00_mailbox_command+0x246/0x444 [qla2xxx] [c0128487] autoremove_wake_function+0x1b/0x40 [f88beb05] qla2x00_mbx_reg_test+0x5d/0xa0 [qla2xxx] [c01161e1] release_console_sem+0xa9/0xb4 [c01ae350] __delay+0x10/0x14 [f88bae73] qla2x00_chip_diag+0x23b/0x29c [qla2xxx] [f88ba5c8] gcc2_compiled.+0x108/0x22c [qla2xxx] [f88b76aa] qla2x00_probe_one+0x42e/0x874 [qla2xxx] [f88d0012] gcc2_compiled.+0x12/0x18 [qla2300] [c01b2424] pci_device_probe_static+0x2c/0x40 [c01b2457] __pci_device_probe+0x1f/0x34 [c01b2488] pci_device_probe+0x1c/0x34 [c01d918d] driver_probe_device+0x41/0x64 [c01d9260] driver_attach+0x34/0x68 [c01d96bb] bus_add_driver+0x8b/0xbc [c01d9c08] driver_register+0x50/0x54 [c01b2686] pci_register_driver+0x86/0xa0 [f00a] qla2300_init+0xa/0x10 [qla2300] [c012c479] sys_init_module+0x111/0x270 [c0102443] syscall_call+0x7/0xb BUG: using smp_processor_id() in preemptible [0001] code: modprobe/1362 ... -- Patrick Mansfield - 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.11rc2 prints disksize twice
On Mon, Jan 31, 2005 at 01:15:37PM +0100, Olaf Hering wrote:
I think its not a functional problem,
but parts of the disk detection is printed twice.
Yes ...
...
SCSI device sdc: 71096640 512-byte hdwr sectors (36401 MB)
SCSI device sdc: drive cache: write through
SCSI device sdc: 71096640 512-byte hdwr sectors (36401 MB)
SCSI device sdc: drive cache: write through
...
I looked into it some, there was a change from Al to always set
bd_invalidated in register_disk(), and then to call blkdev_get. This means
the block_dev.c do_open will call rescan_partitions, and in turn call
revalidate_disk even for non-removable media.
This change:
http://linux.bkbits.net:8080/linux-2.5/diffs/fs/partitions/[EMAIL
PROTECTED]|src/|src/fs|src/fs/partitions|hist/fs/partitions/check.c
The log comment from Al says Work around devices with bogus media change
indication on the first open.
Al - What did that fix? Why was that done in the generic block code, and
not the affected driver (multiple revalidate_disk call in the
driver on device discovery)?
I tested this patch with scsi fixed and removable disks with no problems,
but it could break whatever Al fixed. Otherwise it should work with any
block driver that calls (for removable/modifiable media) check_disk_change
on open and that has a revalidate_disk function and the device is not
broken (it looks like that is the correct use of the two functions, I'm
not certain).
diff -uprN -X /home/patman/dontdiff linux-2.6.11-rc1/fs/partitions/check.c
no-double-sd-linux-2.6.11-rc1/fs/partitions/check.c
--- linux-2.6.11-rc1/fs/partitions/check.c Fri Dec 24 13:35:28 2004
+++ no-double-sd-linux-2.6.11-rc1/fs/partitions/check.c Fri Jan 21 11:19:00 2005
@@ -375,8 +375,6 @@ int rescan_partitions(struct gendisk *di
bdev-bd_invalidated = 0;
for (p = 1; p disk-minors; p++)
delete_partition(disk, p);
- if (disk-fops-revalidate_disk)
- disk-fops-revalidate_disk(disk);
if (!get_capacity(disk) || !(state = check_partition(disk, bdev)))
return 0;
for (p = 1; p state-limit; p++) {
-- Patrick Mansfield
-
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: Mid-layer handling of NOT_READY conditions...
On Mon, Jan 31, 2005 at 11:56:02AM -0500, [EMAIL PROTECTED] wrote: On Sat, 2005-01-29 at 11:34 -0800, Patrick Mansfield wrote: Why not just set scmd-retries to zero in scsi_requeue_command()? This is exactly what I was thinking would be a fairly straight-forward approach at solving the problem... This is ultimately a hack, and raises the potential for the retries value to perpetually be rezero'd. The better solution is the use the block primitives available to avoid the i/o being issued at all if the transport can't handle it. No, it does not change the potential to retry forever, someone still has to requeue the IO again outside of the NEEDS_RETRY/scsi_retry_command case for that to happen. We only check retries in scsi_decide_disposition (well not counting error handling), and if we hit the limit, return SUCCESS. The change is that we reset retries to zero if the command is *not* retried via NEEDS_RETRY/scsi_retry_command. It would be even clearer to zero retries in scsi_decide_disposition. For NOT_READY, we would be better off always using the scsi_requeue_command path ever: get rid of the check in scsi_check_sense, as it will be requeued via scsi_io_completion code. This would have to happen even if delaying retries to NOT_READY devices. But yes, it is better to stop IO if the transport can't handle it, and would likely avoid the problem (if we only got NOT_READY's and never returned DID_BUS_BUSY). But it is still a bug to not reset retries. Maybe I need to hack scsi_debug to demonstrate the problem ... -- Patrick Mansfield - 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: Mid-layer handling of NOT_READY conditions...
On Sat, Jan 29, 2005 at 10:44:41AM -0600, James Bottomley wrote: On Fri, 2005-01-28 at 21:46 -0800, Andrew Vasquez wrote: Returning back DID_IMM_RETRY for these 'transport' related conditions would of course help in this issue -- but at the same time bring with it several side-effects which may not be desirable. So, beyond this particular circumstance, what would be considered a 'proper' return status for this type of event? Well, the correct return, since this is a condition from the storage, is simply the check condition and the sense code (rather than having the driver interpret it). But the transport hit a failure, not the storage device. I thought Andrew hit this sequence: - pull / replace cable - IO resumes but gets NOT_READY (the device could be logging back into the fibre or such) - a FC transport problem is hit, DID_BUSY_BUSY is returned, but scmd-retries has already been exhausted by the NOT_READY Did I misread something? Would this be an approach to consider? Or should we tackle the problem by addressing the quirky (cmd-retries cmd-allowed) state? That's what I think the correct approach should bewe have a few other quirky devices that aren't pleased with our current NOT_READY handling. Were you going to look into coding up a patch for this? We don't track what errors caused a retry (doing so is too painful), or reset the retries. In scsi_decide_disposition() if we get a few retry cases for one or multiple errors, and then a different error that should reasonably be a retry case, we return SUCCESS instead of NEEDS_RETRY. Why not just set scmd-retries to zero in scsi_requeue_command()? All callers are cases that we want to keep retrying if other errors are hit, and would fix other potential retry problems, not only the NOT_READY case. [There is one bad looking scsi_requeue_command() for UNIT_ATTENTION that looks like it could retry forever, independent of this problem.] Fixing the NOT_READY case to quiesce (and not incrementing retries) would fix the problem or make it much less likely, and is still a good idea. And as a long term goal, losing the retry count and moving to allowing all retries for a period of time would avoid other potential problems, and not be tied to the speed of the system. -- Patrick Mansfield - 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: How to add/drop SCSI drives from within the driver?
Atul - On Tue, Jan 25, 2005 at 11:27:36AM -0500, Mukker, Atul wrote: After writing the - - - to the scan attribute, the management applications assume the udev has created the relevant entries in the /dev directly and try to use the devices _immediately_ and fail to see the devices Is there a hotplug event which would tell the management applications that the device nodes have actually been created now and ready to be used? Read the udev man page section, the part right before FILES. Try putting a script under /etc/dev.d/default/*.dev. Then you can get more specific with an /etc/dev.d/scsi/*.dev script or something else. I just tried something simple but did not get it working. Try [EMAIL PROTECTED] list for help. -- Patrick Mansfield - 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: Problems with scsi_scan.c
On Tue, Jun 19, 2001 at 11:08:40AM -0700, Poul Petersen wrote:
This way, the device at LUN 0 is found to start the scan, and
then later
On a more general question - in order to work around the
Zzyzx problem, I have moved the call to get_device_flags
as before and added (I also removed all traces of BLIST_FORCESCAN)
bflags = get_device_flags (scsi_result);
if (bflags BLIST_SPARSELUN) {*sparse_lun = 1;}
if (SRpnt-sr_result) {
scsi_release_request(SRpnt);
return 0; /* assume no peripheral if any sort of error
*/
}
...
The above is a good idea, but the get/check of the flags should
happen after the sr_result.
This way, even though the peripheral qualifier check exits, the
sparse_lun parameter gets set first so scanning can continue on the
Zzyzx device.
BTW, what should the peripheral qualifier be returned as
when scanning LUN 0 of a multiple LUN capable device which has no devices;
for example if the RocketStor had no LUN mappings? If it should return
011b in this case, then the above modification would scan all the LUNs,
while the original code would not. If it still returns 001b, then there
won't be any difference...
A peripheral qualifier (PQ) of 011b should not halt the scan for a sparse
LUN device - current behaviour without your change above is to halt all
scans if LUN 0 has 011b, but for sparse LUN devices, if LUN 0 is found,
other LUNs with 011b would not halt the scan.
I think the SCSI spec is a little vague on what a PQ of 011b means, it says
(SPC-2 R19, ftp://ftp.t10.org/t10/drafts/spc2/spc2r19.pdf) for PQ values
of 001b and 011b:
001b
The device server is capable of supporting the specified peripheral device
type on this logical unit. However, the physical device is not currently
connected to this logical unit.
011b
The device server is not capable of supporting a physical device on this
logical unit. For this peripheral qualifier the peripheral device type
shall be set to 1Fh to provide compatibility with previous versions of
SCSI. All other peripheral device type values are reserved for this
peripheral qualifier.
not capable seems somewhat ambiguous for cases where the device does not
currently have a LUN mapped - the device is currently not capable of
handling the LUN; 001b seems more appropriate, even though the device
will not ever be connected.
For linux, returning a 001b can be bad, as it will allocate a Scsi_Device,
and use up an sd entry (and you can never access the device). Doug Ledford
posted a patch to skip these (apparently it is included in the redhat
7.1 2.4.2-2 kernel).
You might want to check the specs, and see if you can modify the PQ value
returned - some array devices can be configured to return different PQ
values, since different operating systems behave differently based on
the PQ.
-- Patrick Mansfield
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
Re: Who maintains the Fibre Channel QLogic SCSI drivers?
Ben - I don't know who maintains them, but I've been succesfully using the beta driver below with the ISP2200 card, and 2.4.2-ac20 kernel. I've only run with it using low IO loads. I found it linked from here: http://www.qlogic.com/bbs-html/csg_web/adapter_pages/driver_pages/21xx/21linux.html Specifically: http://www.qlogic.com/bbs-html/csg_web/drivers/linux/22xx/qla2x00src-4.24Beta.tgz I had a similiar issue with the qlogicisp.c driver (per email sent by Mike Anderson), no one answered if it was supported or not. -- Patrick Mansfield I know my question (about "this should not happen" messages appearing in the logs followed by a reboot with a QLogic ISP2100 Fibre Channel SCSI card) was complicated, so I'm not surprised nobody could answer it. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED]
