Re: [PATCH] add bsg queue resize
On Sat, Jan 20 2007, FUJITA Tomonori wrote: This enables bsg to resize the queue depth via SG_SET_COMMAND_Q. bsg_command structures are allocated via mempool because the previous way to use contiguous memory makes it difficult to resize the queue depth when a bsg_device has outstanding commands. Overall the patch looks fine. I don't think we need a mempool though, and allocations could just use GFP_USER from the user invoked queuing paths. Just make it GFP_USER, we can always extend the bsg_alloc_command() to take a gfp_t argument as well If you get rid of the mempool, then resizing is simply just adjusting bd-max_queue. -- Jens Axboe - 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
[RFC 2/6] bidi support: request_io_part
The patch was probably too big and did not go through the mailing list. I have compressed and attached it, is that OK or must I put it online somewhere? - Extract all I/O members of struct request into a request_io_part member. - Define API to access the I/O part - Adjust block layer accordingly. - Change all users to new API. At this stage it is all still uni-directional but the intention is clear. Signed-off-by: Benny Halevy [EMAIL PROTECTED] Signed-off-by: Boaz Harrosh [EMAIL PROTECTED] --- arch/um/drivers/ubd_kern.c | 12 +- block/as-iosched.c | 16 ++-- block/cfq-iosched.c | 14 ++-- block/deadline-iosched.c|6 +- block/elevator.c| 26 +++--- block/ll_rw_blk.c | 207 --- block/scsi_ioctl.c |4 +- drivers/acorn/block/fd1772.c| 18 ++-- drivers/acorn/block/mfmhd.c | 23 +++-- drivers/block/DAC960.c |6 +- drivers/block/amiflop.c | 10 +- drivers/block/ataflop.c | 18 ++-- drivers/block/cciss.c | 26 +++--- drivers/block/cpqarray.c| 12 +- drivers/block/floppy.c | 50 +- drivers/block/nbd.c | 14 ++-- drivers/block/paride/pcd.c |4 +- drivers/block/paride/pd.c |8 +- drivers/block/paride/pf.c |6 +- drivers/block/ps2esdi.c | 10 +- drivers/block/swim3.c | 32 +++--- drivers/block/sx8.c |8 +- drivers/block/ub.c | 18 ++-- drivers/block/viodasd.c |8 +- drivers/block/xd.c |4 +- drivers/block/z2ram.c |6 +- drivers/cdrom/aztcd.c | 34 +++--- drivers/cdrom/cdrom.c |2 +- drivers/cdrom/cdu31a.c |4 +- drivers/cdrom/cm206.c |6 +- drivers/cdrom/gscd.c| 20 ++-- drivers/cdrom/mcdx.c| 12 +- drivers/cdrom/optcd.c | 32 +++--- drivers/cdrom/sbpcd.c | 26 +++--- drivers/cdrom/sjcd.c| 32 +++--- drivers/cdrom/sonycd535.c |4 +- drivers/cdrom/viocd.c |4 +- drivers/ide/ide-cd.c| 189 ++- drivers/ide/ide-disk.c |6 +- drivers/ide/ide-dma.c |6 +- drivers/ide/ide-floppy.c| 16 ++-- drivers/ide/ide-io.c| 22 ++-- drivers/ide/ide-lib.c |2 +- drivers/ide/ide-tape.c | 32 +++--- drivers/ide/ide-taskfile.c | 21 +++-- drivers/ide/legacy/hd.c | 26 +++--- drivers/ide/pci/pdc202xx_old.c |2 +- drivers/md/dm-emc.c |3 +- drivers/message/i2o/i2o_block.c | 22 ++-- drivers/mmc/mmc_block.c |6 +- drivers/mtd/mtd_blkdevs.c |4 +- drivers/s390/block/dasd.c |2 +- drivers/s390/block/dasd_diag.c |4 +- drivers/s390/block/dasd_eckd.c |6 +- drivers/s390/block/dasd_fba.c |6 +- drivers/s390/char/tape_34xx.c |2 +- drivers/s390/char/tape_3590.c |2 +- drivers/s390/char/tape_block.c |4 +- drivers/sbus/char/jsflash.c |4 +- drivers/scsi/eata.c | 22 ++-- drivers/scsi/ide-scsi.c |2 +- drivers/scsi/scsi_lib.c | 43 drivers/scsi/scsi_tgt_lib.c | 16 ++-- drivers/scsi/sd.c | 16 ++-- drivers/scsi/sr.c | 14 ++-- drivers/scsi/u14-34f.c | 16 ++-- include/linux/blkdev.h | 99 --- include/linux/blktrace_api.h|7 +- include/linux/elevator.h|2 +- 69 files changed, 707 insertions(+), 659 deletions(-) Total size :148.5 KB Compressed Size: 36.6 KB - 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
[RFC 2/6] bidi support: request_io_part
The patch was probably too big and did not go through the mailing list. I have compressed and attached it, is that OK or must I put it online somewhere? - Extract all I/O members of struct request into a request_io_part member. - Define API to access the I/O part - Adjust block layer accordingly. - Change all users to new API. At this stage it is all still uni-directional but the intention is clear. Signed-off-by: Benny Halevy [EMAIL PROTECTED] Signed-off-by: Boaz Harrosh [EMAIL PROTECTED] --- arch/um/drivers/ubd_kern.c | 12 +- block/as-iosched.c | 16 ++-- block/cfq-iosched.c | 14 ++-- block/deadline-iosched.c|6 +- block/elevator.c| 26 +++--- block/ll_rw_blk.c | 207 --- block/scsi_ioctl.c |4 +- drivers/acorn/block/fd1772.c| 18 ++-- drivers/acorn/block/mfmhd.c | 23 +++-- drivers/block/DAC960.c |6 +- drivers/block/amiflop.c | 10 +- drivers/block/ataflop.c | 18 ++-- drivers/block/cciss.c | 26 +++--- drivers/block/cpqarray.c| 12 +- drivers/block/floppy.c | 50 +- drivers/block/nbd.c | 14 ++-- drivers/block/paride/pcd.c |4 +- drivers/block/paride/pd.c |8 +- drivers/block/paride/pf.c |6 +- drivers/block/ps2esdi.c | 10 +- drivers/block/swim3.c | 32 +++--- drivers/block/sx8.c |8 +- drivers/block/ub.c | 18 ++-- drivers/block/viodasd.c |8 +- drivers/block/xd.c |4 +- drivers/block/z2ram.c |6 +- drivers/cdrom/aztcd.c | 34 +++--- drivers/cdrom/cdrom.c |2 +- drivers/cdrom/cdu31a.c |4 +- drivers/cdrom/cm206.c |6 +- drivers/cdrom/gscd.c| 20 ++-- drivers/cdrom/mcdx.c| 12 +- drivers/cdrom/optcd.c | 32 +++--- drivers/cdrom/sbpcd.c | 26 +++--- drivers/cdrom/sjcd.c| 32 +++--- drivers/cdrom/sonycd535.c |4 +- drivers/cdrom/viocd.c |4 +- drivers/ide/ide-cd.c| 189 ++- drivers/ide/ide-disk.c |6 +- drivers/ide/ide-dma.c |6 +- drivers/ide/ide-floppy.c| 16 ++-- drivers/ide/ide-io.c| 22 ++-- drivers/ide/ide-lib.c |2 +- drivers/ide/ide-tape.c | 32 +++--- drivers/ide/ide-taskfile.c | 21 +++-- drivers/ide/legacy/hd.c | 26 +++--- drivers/ide/pci/pdc202xx_old.c |2 +- drivers/md/dm-emc.c |3 +- drivers/message/i2o/i2o_block.c | 22 ++-- drivers/mmc/mmc_block.c |6 +- drivers/mtd/mtd_blkdevs.c |4 +- drivers/s390/block/dasd.c |2 +- drivers/s390/block/dasd_diag.c |4 +- drivers/s390/block/dasd_eckd.c |6 +- drivers/s390/block/dasd_fba.c |6 +- drivers/s390/char/tape_34xx.c |2 +- drivers/s390/char/tape_3590.c |2 +- drivers/s390/char/tape_block.c |4 +- drivers/sbus/char/jsflash.c |4 +- drivers/scsi/eata.c | 22 ++-- drivers/scsi/ide-scsi.c |2 +- drivers/scsi/scsi_lib.c | 43 drivers/scsi/scsi_tgt_lib.c | 16 ++-- drivers/scsi/sd.c | 16 ++-- drivers/scsi/sr.c | 14 ++-- drivers/scsi/u14-34f.c | 16 ++-- include/linux/blkdev.h | 99 --- include/linux/blktrace_api.h|7 +- include/linux/elevator.h|2 +- 69 files changed, 707 insertions(+), 659 deletions(-) Total size :148.5 KB Compressed Size: 36.6 KB 2of6-request_io_part.patch.tar.gz Description: GNU Zip compressed data
Re: Linux Virtual SCSI HBAs and Virtual disks
Hi Stefan Richter,
Thanks everyone for their advice on this. As per your advice, I did the
following when the last user space target serving the scsi_host quits,
the queue command will do the following on the new commands coming through.
sc-result = DID_NO_CONNECT 16;
sc-resid = sc-request_bufflen;
set_sensedata_commfailure(sc); -
This sets the sense buffer with Device Not ready/Logical Unit
Commincation failure.
done(sc);
The scsi_host will remain in the kernel. Let the EH thread handle the
queued commands (If any). If the user target wants to reconnects to the
same scsi_host, it can do so (Just re-run the user space target again
with same command line paramters). This connection from newly started
target will make the HBA healthy again and start serving IO.
I implemented a new IOCTL to remove this scsi_host if the user
process really needs to. This removal will first finish all the SCSI
commands (With the above status results) queued on the scsi_host (If at
all) and then remove the scsi_host. Also the module unload will delete
all the scsi_hosts created after finishing all the commands queued with
the above status and sense information.
I also implemented passing of sense code information from user space to
sense_buffer. A little more work needs to be done on this.
Also, I need to make sure that all the locking used inside is correctly
implemented to prevent dead locks and improve efficiency.
The new version is available http://vscsihba.aboo.org/vscsihbav204.gz
Aboo
Stefan Richter wrote:
aboo wrote:
Can I use the following method safely to know if a scsi_device is
open or not?
if ( atomic_read(sdev-sdev_gendev.kobj.kref.refcount) 14 ) {
//sdev is in use
}
No, this too relies far too much on implementation details of upper
layers. (Besides, what if the device is opened right after that? The
atomic refcount is not enough, something mutex-like would be necessary
to do anything useful with the information open/not open.) Ideally,
your LLD sticks with what the Linux SCSI mid-low API has to offer. Thus
your LLD is only aware of this API, but *not* of implementation details
of the SCSI core, let alone SCSI high-level drivers or block I/O
subsystem or whatever other upper layer.
And in the end, why should vscsihba care whether a scsi_device is in use
or not? If a userspace device server quits or got killed or crashed,
simply let vscsihba request the removal of the scsi_device (or the
entire host if there is only one device per host). Whoever opened the
device cannot do anything useful with it anymore anyway when there is no
device server.
Of course it is not entirely as simple as it sounds. As mentioned, if
vscsihba becomes aware that a device server quit or crashed, let your
queuecommand hook finish all newly incoming commands immediately instead
of enqueueing them. Dequeue and finish all outstanding commands. Make
sure the eh hooks don't wait for something that can't happen anymore.
Note that when the removal of a device is requested, shutdown methods of
high-level drivers like sd become active and may try to issue new
commands (such as to synchronize disk caches). Therein lies potential
for deadlocks or, less critically, for minutes and minutes spent in
futile error recovery attempts.
So, I said you should ignore the in-use state of a scsi_device. Of
course that way you cannot give the userspace device server a status
notification from vscsihba which says keep running for now, somebody is
using your device, or vice versa: your last user went away, you can
safely quit now if you feel like it. But in my opinion you don't really
need such status notification in foreseeable future. vscsihba would
primarily or exclusively be used in controlled setups where the
administrator knows very well when it is safe to terminate a userspace
device server. Besides, you have to take into account anyway that a
userspace device server is killed or crashed when its device was in use.
As I wrote before, deal with it like with hot-unplug. A kernel driver
cannot prevent the user from pulling a cable.
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux Virtual SCSI HBAs and Virtual disks
Aboo Valappil wrote: I implemented a new IOCTL to remove this scsi_host if the user process really needs to. This removal will first finish all the SCSI commands (With the above status results) queued on the scsi_host (If at all) and then remove the scsi_host. Also the module unload will delete all the scsi_hosts created after finishing all the commands queued with the above status and sense information. This is a valid approach, but probably more useful would be something like: - userspace device server or modprobe -r or procfs/sysfs magic or whatever else requests removal of a Scsi_Host (or merely of a single scsi_device), - vscsihba enters scsi_remove_host() or scsi_remove_device(), - SCSI core and upper layers do whatever it takes to withdraw from the respective I-T(-L) nexus gracefully (e.g. synchronize cache, unlock drive door...), - userspace device server handles any previously remaining commands and the new shutdown commands like intended, - SCSI core and upper layers are finished with their business, the respective Scsi_Host or scsi_device does not exist anymore now, vscsihba leaves scsi_remove_host() or scsi_remove_device(), - vscsihba tells userspace device server somehow that there will be no further requests, ever. That way, your virtual device server is exposed to everything which a real device server would be too when a Linux initiator shuts the connection down. Could be interesting to testbed device servers as well as to userspace bridges to real device servers. When implemented, the graceful shutdown path should look almost exactly like the opposite of the start-up path. The hot-unplug path looks a little different because vscsihba has to go through that path without assistance of the userspace server. Ideally, the hot-unplug path would actually be the graceful shutdown path plus a few little extra measures to account for premature absence of the device server. [Of course, I'm saying all this without ever having designed a Linux SCSI LLD myself, only from the background of maintaining an LLD written by other people...] -- Stefan Richter -=-=-=== ---= =-=== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux Virtual SCSI HBAs and Virtual disks
Randy Dunlap wrote: Aboo Valappil wrote: The new version is available http://vscsihba.aboo.org/vscsihbav204.gz 404: NOT FOUND .gz - .tgz Besides the tarball, a browsable source tree would be nice for people who just want to take a quick look. -- Stefan Richter -=-=-=== ---= =-=== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ipr: Tolerate not finding PCI-X registers
Don't fail initialization of an adapter if the PCI-X registers
cannot be found since it may be a PCI-E adapter.
Signed-off-by: Brian King [EMAIL PROTECTED]
---
linux-2.6-bjking1/drivers/scsi/ipr.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff -puN drivers/scsi/ipr.c~ipr_pcie_sas drivers/scsi/ipr.c
--- linux-2.6/drivers/scsi/ipr.c~ipr_pcie_sas 2007-01-17 17:21:10.0
-0600
+++ linux-2.6-bjking1/drivers/scsi/ipr.c2007-01-17 17:21:10.0
-0600
@@ -595,10 +595,8 @@ static int ipr_save_pcix_cmd_reg(struct
{
int pcix_cmd_reg = pci_find_capability(ioa_cfg-pdev, PCI_CAP_ID_PCIX);
- if (pcix_cmd_reg == 0) {
- dev_err(ioa_cfg-pdev-dev, Failed to save PCI-X command
register\n);
- return -EIO;
- }
+ if (pcix_cmd_reg == 0)
+ return 0;
if (pci_read_config_word(ioa_cfg-pdev, pcix_cmd_reg + PCI_X_CMD,
ioa_cfg-saved_pcix_cmd_reg) !=
PCIBIOS_SUCCESSFUL) {
@@ -627,10 +625,6 @@ static int ipr_set_pcix_cmd_reg(struct i
dev_err(ioa_cfg-pdev-dev, Failed to setup PCI-X
command register\n);
return -EIO;
}
- } else {
- dev_err(ioa_cfg-pdev-dev,
- Failed to setup PCI-X command register\n);
- return -EIO;
}
return 0;
_
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ipr: PCI error recovery fix
Since the pci_block_user_cfg_access API was modified to track
block/unblocks, it was discovered that the ipr driver had a
path through its code (in PCI error recovery) which would unblock
when not previously blocked.
Signed-off-by: Brian King [EMAIL PROTECTED]
---
linux-2.6-bjking1/drivers/scsi/ipr.c | 21 +++--
1 files changed, 19 insertions(+), 2 deletions(-)
diff -puN drivers/scsi/ipr.c~ipr_eeh_recovery_fix drivers/scsi/ipr.c
--- linux-2.6/drivers/scsi/ipr.c~ipr_eeh_recovery_fix 2007-01-18
17:08:08.0 -0600
+++ linux-2.6-bjking1/drivers/scsi/ipr.c2007-01-18 17:08:08.0
-0600
@@ -6308,7 +6308,6 @@ static int ipr_reset_restore_cfg_space(s
int rc;
ENTER;
- pci_unblock_user_cfg_access(ioa_cfg-pdev);
rc = pci_restore_state(ioa_cfg-pdev);
if (rc != PCIBIOS_SUCCESSFUL) {
@@ -6349,6 +6348,24 @@ static int ipr_reset_restore_cfg_space(s
}
/**
+ * ipr_reset_bist_done - BIST has completed on the adapter.
+ * @ipr_cmd: ipr command struct
+ *
+ * Description: Unblock config space and resume the reset process.
+ *
+ * Return value:
+ * IPR_RC_JOB_CONTINUE
+ **/
+static int ipr_reset_bist_done(struct ipr_cmnd *ipr_cmd)
+{
+ ENTER;
+ pci_unblock_user_cfg_access(ipr_cmd-ioa_cfg-pdev);
+ ipr_cmd-job_step = ipr_reset_restore_cfg_space;
+ LEAVE;
+ return IPR_RC_JOB_CONTINUE;
+}
+
+/**
* ipr_reset_start_bist - Run BIST on the adapter.
* @ipr_cmd: ipr command struct
*
@@ -6370,7 +6387,7 @@ static int ipr_reset_start_bist(struct i
ipr_cmd-ioasa.ioasc = cpu_to_be32(IPR_IOASC_PCI_ACCESS_ERROR);
rc = IPR_RC_JOB_CONTINUE;
} else {
- ipr_cmd-job_step = ipr_reset_restore_cfg_space;
+ ipr_cmd-job_step = ipr_reset_bist_done;
ipr_reset_start_timer(ipr_cmd, IPR_WAIT_FOR_BIST_TIMEOUT);
rc = IPR_RC_JOB_RETURN;
}
_
-
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 4/4] ipr: Driver version 2.3.1
Bump driver version to 2.3.1. Signed-off-by: Brian King [EMAIL PROTECTED] --- linux-2.6-bjking1/drivers/scsi/ipr.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff -puN drivers/scsi/ipr.h~ipr_driver_version_2_3_1 drivers/scsi/ipr.h --- linux-2.6/drivers/scsi/ipr.h~ipr_driver_version_2_3_1 2007-01-23 11:01:15.0 -0600 +++ linux-2.6-bjking1/drivers/scsi/ipr.h2007-01-23 11:24:28.0 -0600 @@ -37,8 +37,8 @@ /* * Literals */ -#define IPR_DRIVER_VERSION 2.3.0 -#define IPR_DRIVER_DATE (November 8, 2006) +#define IPR_DRIVER_VERSION 2.3.1 +#define IPR_DRIVER_DATE (January 23, 2007) /* * IPR_MAX_CMD_PER_LUN: This defines the maximum number of outstanding _ - 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/4] ipr: Remove usage of pci driver data
Since ipr handles dynamic ids, it must handle driver_data
not being set, so remove the current usage of driver_data
so it can be used for other things in future patches.
Signed-off-by: Brian King [EMAIL PROTECTED]
---
linux-2.6-bjking1/drivers/scsi/ipr.c | 63 +++
1 files changed, 20 insertions(+), 43 deletions(-)
diff -puN drivers/scsi/ipr.c~ipr_driver_data_fixup drivers/scsi/ipr.c
--- linux-2.6/drivers/scsi/ipr.c~ipr_driver_data_fixup 2007-01-18
17:08:05.0 -0600
+++ linux-2.6-bjking1/drivers/scsi/ipr.c2007-01-18 17:08:05.0
-0600
@@ -7166,9 +7166,6 @@ ipr_get_chip_cfg(const struct pci_device
{
int i;
- if (dev_id-driver_data)
- return (const struct ipr_chip_cfg_t *)dev_id-driver_data;
-
for (i = 0; i ARRAY_SIZE(ipr_chip); i++)
if (ipr_chip[i].vendor == dev_id-vendor
ipr_chip[i].device == dev_id-device)
@@ -7517,65 +7514,45 @@ static void ipr_shutdown(struct pci_dev
static struct pci_device_id ipr_pci_table[] __devinitdata = {
{ PCI_VENDOR_ID_MYLEX, PCI_DEVICE_ID_IBM_GEMSTONE,
- PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_5702,
- 0, 0, (kernel_ulong_t)ipr_chip_cfg[0] },
+ PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_5702, 0, 0, 0 },
{ PCI_VENDOR_ID_MYLEX, PCI_DEVICE_ID_IBM_GEMSTONE,
- PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_5703,
- 0, 0, (kernel_ulong_t)ipr_chip_cfg[0] },
+ PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_5703, 0, 0, 0 },
{ PCI_VENDOR_ID_MYLEX, PCI_DEVICE_ID_IBM_GEMSTONE,
- PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_573D,
- 0, 0, (kernel_ulong_t)ipr_chip_cfg[0] },
+ PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_573D, 0, 0, 0 },
{ PCI_VENDOR_ID_MYLEX, PCI_DEVICE_ID_IBM_GEMSTONE,
- PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_573E,
- 0, 0, (kernel_ulong_t)ipr_chip_cfg[0] },
+ PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_573E, 0, 0, 0 },
{ PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_CITRINE,
- PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_571B,
- 0, 0, (kernel_ulong_t)ipr_chip_cfg[0] },
+ PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_571B, 0, 0, 0 },
{ PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_CITRINE,
- PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_572E,
- 0, 0, (kernel_ulong_t)ipr_chip_cfg[0] },
+ PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_572E, 0, 0, 0 },
{ PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_CITRINE,
- PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_571A,
- 0, 0, (kernel_ulong_t)ipr_chip_cfg[0] },
+ PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_571A, 0, 0, 0 },
{ PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_CITRINE,
- PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_575B,
- 0, 0, (kernel_ulong_t)ipr_chip_cfg[0] },
+ PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_575B, 0, 0, 0 },
{ PCI_VENDOR_ID_ADAPTEC2, PCI_DEVICE_ID_ADAPTEC2_OBSIDIAN,
- PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_572A,
- 0, 0, (kernel_ulong_t)ipr_chip_cfg[0] },
+ PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_572A, 0, 0, 0 },
{ PCI_VENDOR_ID_ADAPTEC2, PCI_DEVICE_ID_ADAPTEC2_OBSIDIAN,
- PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_572B,
- 0, 0, (kernel_ulong_t)ipr_chip_cfg[0] },
+ PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_572B, 0, 0, 0 },
{ PCI_VENDOR_ID_ADAPTEC2, PCI_DEVICE_ID_ADAPTEC2_OBSIDIAN,
- PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_575C,
- 0, 0, (kernel_ulong_t)ipr_chip_cfg[0] },
+ PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_575C, 0, 0, 0 },
{ PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_OBSIDIAN,
- PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_572A,
- 0, 0, (kernel_ulong_t)ipr_chip_cfg[0] },
+ PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_572A, 0, 0, 0 },
{ PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_OBSIDIAN,
- PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_572B,
- 0, 0, (kernel_ulong_t)ipr_chip_cfg[0] },
+ PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_572B, 0, 0, 0 },
{ PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_OBSIDIAN,
- PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_575C,
- 0, 0, (kernel_ulong_t)ipr_chip_cfg[0] },
+ PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_575C, 0, 0, 0 },
{ PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_OBSIDIAN,
- PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_57B8,
- 0, 0, (kernel_ulong_t)ipr_chip_cfg[0] },
+ PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_57B8, 0, 0, 0 },
{ PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_OBSIDIAN_E,
- PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_57B7,
- 0, 0, (kernel_ulong_t)ipr_chip_cfg[0] },
+ PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_57B7, 0, 0, 0 },
{ PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_SNIPE,
- PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_2780,
Re: [RFC 3/6] bidi support: bidirectional request
James Bottomley wrote: On Mon, 2007-01-22 at 01:25 +0200, Boaz Harrosh wrote: - Instantiate another request_io_part in request for bidi_read. - Define Implement new API for accessing bidi parts. - API to Build bidi requests and map to sglists. - Define new end_that_request_block() function to end a complete request. Actually, this approach looks to be a bit too narrow. You seem to be predicating on the idea that the bidirectional will transfer in and out of the same area. For some of the frame in/frame out stuff, we probably need the read and write areas for the bidirectional request to be separated. Hmm, our proposal introduces two separate and independent i/o areas. One used for uni-directional transfers and for bidi data output, the other is used for bidi data input so we're in agreement. Benny - 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 1/6] bidi support: request dma_data_direction
Muli Ben-Yehuda wrote:
On Mon, Jan 22, 2007 at 01:21:28AM +0200, Boaz Harrosh wrote:
- Introduce a new enum dma_data_direction data_dir member in struct request.
and remove the RW bit from request-cmd_flag
Some architecture use 'enum dma_data_direction' and some 'int
dma_data_direction'. The consensus was to move to int over
time. Please use 'int dma_data_direction'.
That should be fine (although I'm not sure what made you go this way :)
Please see my reply to Douglas, proposing an enum req_io_direction
at the block layer and up which will provide a better enumeration
for our use.
+static inline int dma_write_dir(enum dma_data_direction dir)
+{
+return (dir == DMA_TO_DEVICE) || (dir == DMA_BIDIRECTIONAL);
+}
write can mean write to device or write to memory, depending on
context. Not exactly something which should be a generic
helper. Rename to 'dma_to_device(int dir)'?
much better. thanks!
+static inline int dma_uni_dir(enum dma_data_direction dir)
+{
+return (dir == DMA_TO_DEVICE) || (dir == DMA_FROM_DEVICE) ||
+ (dir == DMA_NONE);
+}
While this doesn't look very useful. Why is DMA_NONE a uni-dir? I
suggest replacing this with an open coded (dir != DMA_BIDIRECTIONAL).
The idea was to be resilient to invalid values. (dir != DMA_BIDIRECTIONAL)
is fine of course, but I'd add a BUG_ON such as (dir 0 || dir
DMA_BIDIRECTIONAL)
Benny
-
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 1/6] bidi support: request dma_data_direction
Douglas Gilbert wrote:
Benny Halevy wrote:
Douglas Gilbert wrote:
Perhaps the right use of DMA_BIRECTIONAL needs to be
defined.
Could it be used with a XDWRITE(10) SCSI command
defined in sbc3r07.pdf at http://www.t10.org ? I suspect
using two scatter gather lists would be a better approach.
Exactly. This is a classic example of a bidirectional command
and indeed two scatter-gather lists (that are mapped into two
bio lists) are used.
- Introduce new blk_rq_init_unqueued_req() and use it in places ad-hoc
requests were used and bzero'ed.
With a bi-directional transfer is it always unambiguous
which transfer occurs first (or could they occur at
the same time)?
The bidi transfers can occur in any order and in parallel.
Then it is not sufficient for modern SCSI transports in which
certain bidirectional commands (probably most) have a well
defined order.
So DMA_BIDIRECTIONAL looks PCI specific and it may have
been a mistake to replace other subsystem's direction flags
with it. RDMA might be an interesting case.
I would say that it might make sense to define an equivalent
for dma_data_direction at the block layer, for example:
enum req_io_direction {
REQ_IO_NONE = 0,
REQ_IN_FROM_DEVICE = 1,
REQ_OUT_TO_DEVICE = 2,
REQ_BIDIRECTIONAL = 3,
};
can be used in struct request and upper layers.
Besides the fact that having separate I/O buffers for bidirectional
transfers makes block I/O different from pci bidi I/O,
this enum makes more sense arithmetically and has
a much better meaning for the zero value.
Today DMA_BIDIRECTIONAL is used in several places as the default and invalid
value since no-one ever used it before. I'd rather have the value 0 mean
REQ_IO_NONE (or REQ_IO_INVALID if we want such thing).
Benny
-
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 1/6] bidi support: request dma_data_direction
On Tue, Jan 23, 2007 at 03:45:00PM +0200, Benny Halevy wrote:
+static inline int dma_uni_dir(enum dma_data_direction dir)
+{
+ return (dir == DMA_TO_DEVICE) || (dir == DMA_FROM_DEVICE) ||
+ (dir == DMA_NONE);
+}
While this doesn't look very useful. Why is DMA_NONE a uni-dir? I
suggest replacing this with an open coded (dir != DMA_BIDIRECTIONAL).
The idea was to be resilient to invalid values. (dir != DMA_BIDIRECTIONAL)
is fine of course, but I'd add a BUG_ON such as (dir 0 || dir
DMA_BIDIRECTIONAL)
If DMA_NONE isn't actually allowed here, you can use valid_dma_direction().
Cheers,
Muli
-
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 1/6] bidi support: request dma_data_direction
Muli Ben-Yehuda wrote:
On Tue, Jan 23, 2007 at 03:45:00PM +0200, Benny Halevy wrote:
+static inline int dma_uni_dir(enum dma_data_direction dir)
+{
+ return (dir == DMA_TO_DEVICE) || (dir == DMA_FROM_DEVICE) ||
+ (dir == DMA_NONE);
+}
While this doesn't look very useful. Why is DMA_NONE a uni-dir? I
suggest replacing this with an open coded (dir != DMA_BIDIRECTIONAL).
The idea was to be resilient to invalid values. (dir != DMA_BIDIRECTIONAL)
is fine of course, but I'd add a BUG_ON such as (dir 0 || dir
DMA_BIDIRECTIONAL)
If DMA_NONE isn't actually allowed here, you can use valid_dma_direction().
DMA_NONE should be allowed as it is used by commands that do no I/O and these
are handled on uni-directional path.
BTW, the BUG_ON I suggested has a bug of course since (countering my intuition)
DMA_BIDIRECTIONAL==0, so it should be BUG_ON(dir 0 || dir DMA_NONE)
instead.
-
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 0/4] aacraid: Driver updates
The following 4 patches contain various updates described in each mail. Patches apply to the scsi-misc-2.6 tree. Makefile |2 aachba.c | 672 - aacraid.h | 46 +++- comminit.c | 14 - commsup.c | 40 --- linit.c|7 rkt.c | 64 +++-- rx.c | 263 +++ sa.c | 33 ++ 9 files changed, 682 insertions(+), 459 deletions(-) -- Mark Haverkamp [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
[PATCH 1/4] aacraid: rework communication support code
Received from Mark Salyzyn,
Replace all if/else communication transports with a platform function call.
This is in recognition of the need to migrate to up-and-coming transports.
Currently the Linux driver does not support two available communication
transports provided by our products, these will be added in future patches, and
will expand the platform function set.
Signed-off-by Mark Haverkamp [EMAIL PROTECTED]
---
--- scsi-misc-aac.orig/drivers/scsi/aacraid/aacraid.h 2007-01-15
10:20:19.0 -0800
+++ scsi-misc-aac/drivers/scsi/aacraid/aacraid.h2007-01-18
10:06:54.0 -0800
@@ -5,6 +5,7 @@
#define _nblank(x) #x
#define nblank(x) _nblank(x)[0]
+#include linux/interrupt.h
/*--
* D E F I N E S
@@ -488,13 +489,20 @@
struct adapter_ops
{
+ /* Low level operations */
void (*adapter_interrupt)(struct aac_dev *dev);
void (*adapter_notify)(struct aac_dev *dev, u32 event);
void (*adapter_disable_int)(struct aac_dev *dev);
+ void (*adapter_enable_int)(struct aac_dev *dev);
int (*adapter_sync_cmd)(struct aac_dev *dev, u32 command, u32 p1, u32
p2, u32 p3, u32 p4, u32 p5, u32 p6, u32 *status, u32 *r1, u32 *r2, u32 *r3, u32
*r4);
int (*adapter_check_health)(struct aac_dev *dev);
- int (*adapter_send)(struct fib * fib);
+ /* Transport operations */
int (*adapter_ioremap)(struct aac_dev * dev, u32 size);
+ irqreturn_t (*adapter_intr)(int irq, void *dev_id);
+ /* Packet operations */
+ int (*adapter_deliver)(struct fib * fib);
+ /* Administrative operations */
+ int (*adapter_comm)(struct aac_dev * dev, int comm);
};
/*
@@ -1018,7 +1026,9 @@
u8 nondasd_support;
u8 dac_support;
u8 raid_scsi_mode;
- u8 new_comm_interface;
+ u8 comm_interface;
+# define AAC_COMM_PRODUCER 0
+# define AAC_COMM_MESSAGE 1
/* macro side-effects BEWARE */
# define raw_io_interface \
init-InitStructRevision==cpu_to_le32(ADAPTER_INIT_STRUCT_REVISION_4)
@@ -1036,18 +1046,24 @@
#define aac_adapter_disable_int(dev) \
(dev)-a_ops.adapter_disable_int(dev)
+#define aac_adapter_enable_int(dev) \
+ (dev)-a_ops.adapter_enable_int(dev)
+
#define aac_adapter_sync_cmd(dev, command, p1, p2, p3, p4, p5, p6, status, r1,
r2, r3, r4) \
(dev)-a_ops.adapter_sync_cmd(dev, command, p1, p2, p3, p4, p5, p6,
status, r1, r2, r3, r4)
#define aac_adapter_check_health(dev) \
(dev)-a_ops.adapter_check_health(dev)
-#define aac_adapter_send(fib) \
- ((fib)-dev)-a_ops.adapter_send(fib)
-
#define aac_adapter_ioremap(dev, size) \
(dev)-a_ops.adapter_ioremap(dev, size)
+#define aac_adapter_deliver(fib) \
+ ((fib)-dev)-a_ops.adapter_deliver(fib)
+
+#define aac_adapter_comm(dev,comm) \
+ (dev)-a_ops.adapter_comm(dev, comm)
+
#define FIB_CONTEXT_FLAG_TIMED_OUT (0x0001)
/*
@@ -1795,6 +1811,7 @@
int aac_rx_init(struct aac_dev *dev);
int aac_rkt_init(struct aac_dev *dev);
int aac_sa_init(struct aac_dev *dev);
+int aac_queue_get(struct aac_dev * dev, u32 * index, u32 qid, struct hw_fib *
hw_fib, int wait, struct fib * fibptr, unsigned long *nonotify);
unsigned int aac_response_normal(struct aac_queue * q);
unsigned int aac_command_normal(struct aac_queue * q);
unsigned int aac_intr_normal(struct aac_dev * dev, u32 Index);
--- scsi-misc-aac.orig/drivers/scsi/aacraid/comminit.c 2007-01-15
10:24:10.0 -0800
+++ scsi-misc-aac/drivers/scsi/aacraid/comminit.c 2007-01-15
10:24:43.0 -0800
@@ -95,7 +95,7 @@
init-HostPhysMemPages = cpu_to_le32(AAC_MAX_HOSTPHYSMEMPAGES);
init-InitFlags = 0;
- if (dev-new_comm_interface) {
+ if (dev-comm_interface == AAC_COMM_MESSAGE) {
init-InitFlags = cpu_to_le32(INITFLAGS_NEW_COMM_SUPPORTED);
dprintk((KERN_WARNINGaacraid: New Comm Interface enabled\n));
}
@@ -297,21 +297,23 @@
- sizeof(struct aac_fibhdr)
- sizeof(struct aac_write) + sizeof(struct sgentry))
/ sizeof(struct sgentry);
- dev-new_comm_interface = 0;
+ dev-comm_interface = AAC_COMM_PRODUCER;
dev-raw_io_64 = 0;
if ((!aac_adapter_sync_cmd(dev, GET_ADAPTER_PROPERTIES,
0, 0, 0, 0, 0, 0, status+0, status+1, status+2, NULL, NULL))
(status[0] == 0x0001)) {
if (status[1] AAC_OPT_NEW_COMM_64)
dev-raw_io_64 = 1;
- if (status[1] AAC_OPT_NEW_COMM)
- dev-new_comm_interface = dev-a_ops.adapter_send != 0;
- if (dev-new_comm_interface (status[2] dev-base_size)) {
+ if
[PATCH 4/4] aacraid: rework packet support code
Received from Mark Salyzyn,
Replace all if/else packet formations with platform function calls. This is in
recognition of the proliferation of read and write packet types, and in the
need to migrate to up-and-coming packets for new products.
Signed-off-by Mark Haverkamp [EMAIL PROTECTED]
---
--- scsi-misc-aac.orig/drivers/scsi/aacraid/aachba.c2007-01-18
10:11:26.0 -0800
+++ scsi-misc-aac/drivers/scsi/aacraid/aachba.c 2007-01-18 10:11:30.0
-0800
@@ -706,6 +706,309 @@
}
}
+static int aac_bounds_32(struct aac_dev * dev, struct scsi_cmnd * cmd, u64 lba)
+{
+ if (lba 0xLL) {
+ int cid = scmd_id(cmd);
+ dprintk((KERN_DEBUG aacraid: Illegal lba\n));
+ cmd-result = DID_OK 16 | COMMAND_COMPLETE 8 |
+ SAM_STAT_CHECK_CONDITION;
+ set_sense((u8 *) dev-fsa_dev[cid].sense_data,
+ HARDWARE_ERROR,
+ SENCODE_INTERNAL_TARGET_FAILURE,
+ ASENCODE_INTERNAL_TARGET_FAILURE, 0, 0,
+ 0, 0);
+ memcpy(cmd-sense_buffer, dev-fsa_dev[cid].sense_data,
+ (sizeof(dev-fsa_dev[cid].sense_data)
sizeof(cmd-sense_buffer))
+ ? sizeof(cmd-sense_buffer)
+ : sizeof(dev-fsa_dev[cid].sense_data));
+ cmd-scsi_done(cmd);
+ return 1;
+ }
+ return 0;
+}
+
+static int aac_bounds_64(struct aac_dev * dev, struct scsi_cmnd * cmd, u64 lba)
+{
+ return 0;
+}
+
+static void io_callback(void *context, struct fib * fibptr);
+
+static int aac_read_raw_io(struct fib * fib, struct scsi_cmnd * cmd, u64 lba,
u32 count)
+{
+ u16 fibsize;
+ struct aac_raw_io *readcmd;
+ aac_fib_init(fib);
+ readcmd = (struct aac_raw_io *) fib_data(fib);
+ readcmd-block[0] = cpu_to_le32((u32)(lba0x));
+ readcmd-block[1] = cpu_to_le32((u32)((lba0xLL)32));
+ readcmd-count = cpu_to_le32(count9);
+ readcmd-cid = cpu_to_le16(scmd_id(cmd));
+ readcmd-flags = cpu_to_le16(1);
+ readcmd-bpTotal = 0;
+ readcmd-bpComplete = 0;
+
+ aac_build_sgraw(cmd, readcmd-sg);
+ fibsize = sizeof(struct aac_raw_io) + ((le32_to_cpu(readcmd-sg.count)
- 1) * sizeof (struct sgentryraw));
+ BUG_ON(fibsize (fib-dev-max_fib_size - sizeof(struct aac_fibhdr)));
+ /*
+* Now send the Fib to the adapter
+*/
+ return aac_fib_send(ContainerRawIo,
+ fib,
+ fibsize,
+ FsaNormal,
+ 0, 1,
+ (fib_callback) io_callback,
+ (void *) cmd);
+}
+
+static int aac_read_block64(struct fib * fib, struct scsi_cmnd * cmd, u64 lba,
u32 count)
+{
+ u16 fibsize;
+ struct aac_read64 *readcmd;
+ aac_fib_init(fib);
+ readcmd = (struct aac_read64 *) fib_data(fib);
+ readcmd-command = cpu_to_le32(VM_CtHostRead64);
+ readcmd-cid = cpu_to_le16(scmd_id(cmd));
+ readcmd-sector_count = cpu_to_le16(count);
+ readcmd-block = cpu_to_le32((u32)(lba0x));
+ readcmd-pad = 0;
+ readcmd-flags = 0;
+
+ aac_build_sg64(cmd, readcmd-sg);
+ fibsize = sizeof(struct aac_read64) +
+ ((le32_to_cpu(readcmd-sg.count) - 1) *
+sizeof (struct sgentry64));
+ BUG_ON (fibsize (fib-dev-max_fib_size -
+ sizeof(struct aac_fibhdr)));
+ /*
+* Now send the Fib to the adapter
+*/
+ return aac_fib_send(ContainerCommand64,
+ fib,
+ fibsize,
+ FsaNormal,
+ 0, 1,
+ (fib_callback) io_callback,
+ (void *) cmd);
+}
+
+static int aac_read_block(struct fib * fib, struct scsi_cmnd * cmd, u64 lba,
u32 count)
+{
+ u16 fibsize;
+ struct aac_read *readcmd;
+ aac_fib_init(fib);
+ readcmd = (struct aac_read *) fib_data(fib);
+ readcmd-command = cpu_to_le32(VM_CtBlockRead);
+ readcmd-cid = cpu_to_le16(scmd_id(cmd));
+ readcmd-block = cpu_to_le32((u32)(lba0x));
+ readcmd-count = cpu_to_le32(count * 512);
+
+ aac_build_sg(cmd, readcmd-sg);
+ fibsize = sizeof(struct aac_read) +
+ ((le32_to_cpu(readcmd-sg.count) - 1) *
+sizeof (struct sgentry));
+ BUG_ON (fibsize (fib-dev-max_fib_size -
+ sizeof(struct aac_fibhdr)));
+ /*
+* Now send the Fib to the adapter
+*/
+ return aac_fib_send(ContainerCommand,
+ fib,
+ fibsize,
+ FsaNormal,
+ 0, 1,
+ (fib_callback)
Re: Linux Virtual SCSI HBAs and Virtual disks
Aboo Valappil wrote: Stefan Richter wrote: ... - vscsihba enters scsi_remove_host() or scsi_remove_device(), - SCSI core and upper layers do whatever it takes to withdraw from the respective I-T(-L) nexus gracefully (e.g. synchronize cache, unlock drive door...), Does this happen automatically when the scsi_remove_host() is called, Yes. The SCSI core passes the remove/shutdown request up to the higher layers like sd_mod for orderly shutdown. There is no distinction between regular shutdown and hot-unplug in SCSI core or above; these layers treat everything as regular shutdown. Only the LLD can (and has to) make this distinction. -- Stefan Richter -=-=-=== ---= ==--- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add bsg queue resize
From: Jens Axboe [EMAIL PROTECTED]
Subject: Re: [PATCH] add bsg queue resize
Date: Tue, 23 Jan 2007 16:23:49 +0100
On Tue, Jan 23 2007, Jens Axboe wrote:
On Sat, Jan 20 2007, FUJITA Tomonori wrote:
This enables bsg to resize the queue depth via
SG_SET_COMMAND_Q. bsg_command structures are allocated via mempool
because the previous way to use contiguous memory makes it difficult
to resize the queue depth when a bsg_device has outstanding commands.
Overall the patch looks fine. I don't think we need a mempool though,
and allocations could just use GFP_USER from the user invoked queuing
paths. Just make it GFP_USER, we can always extend the
bsg_alloc_command() to take a gfp_t argument as well If you get rid of
the mempool, then resizing is simply just adjusting bd-max_queue.
Like so.
Thanks. I thought that pre-allocating bsg_command structures would be
nice. But it doesn't matter much for me.
One minor comment is that we could simplify __bsg_alloc_command
failpath a bit?
---
From 6cebe0e87adc90ba50067f017c52a233fb9262d6 Mon Sep 17 00:00:00 2001
From: FUJITA Tomonori [EMAIL PROTECTED]
Date: Wed, 24 Jan 2007 11:08:47 +0900
Subject: [PATCH] bsg: simplify __bsg_alloc_command failpath
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
block/bsg.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/block/bsg.c b/block/bsg.c
index e97e3ec..c85d961 100644
--- a/block/bsg.c
+++ b/block/bsg.c
@@ -128,7 +128,8 @@ static struct bsg_command *__bsg_alloc_command(struct
bsg_device *bd)
bc = kmem_cache_alloc(bsg_cmd_cachep, GFP_USER);
if (unlikely(!bc)) {
spin_lock_irq(bd-lock);
- goto alloc_fail;
+ bd-queued_cmds--;
+ goto out;
}
memset(bc, 0, sizeof(*bc));
@@ -136,8 +137,6 @@ static struct bsg_command *__bsg_alloc_command(struct
bsg_device *bd)
INIT_LIST_HEAD(bc-list);
dprintk(%s: returning free cmd %p\n, bd-name, bc);
return bc;
-alloc_fail:
- bd-queued_cmds--;
out:
spin_unlock_irq(bd-lock);
return bc;
--
1.4.4.3
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux Virtual SCSI HBAs and Virtual disks
Aboo Valappil wrote: Hi Stefan Richter, Thanks everyone for their advice on this. As per your advice, I did the following when the last user space target serving the scsi_host quits, the queue command will do the following on the new commands coming through. sc-result = DID_NO_CONNECT 16; sc-resid = sc-request_bufflen; set_sensedata_commfailure(sc); - This sets the sense buffer with Device Not ready/Logical Unit Commincation failure. done(sc); The scsi_host will remain in the kernel. Let the EH thread handle the queued commands (If any). If the user target wants to reconnects to the same scsi_host, it can do so (Just re-run the user space target again with same command line paramters). This connection from newly started target will make the HBA healthy again and start serving IO. I implemented a new IOCTL to remove this scsi_host if the user process really needs to. This removal will first finish all the SCSI commands (With the above status results) queued on the scsi_host (If at all) and then remove the scsi_host. Also the module unload will delete all the scsi_hosts created after finishing all the commands queued with the above status and sense information. I also implemented passing of sense code information from user space to sense_buffer. A little more work needs to be done on this. Also, I need to make sure that all the locking used inside is correctly implemented to prevent dead locks and improve efficiency. The new version is available http://vscsihba.aboo.org/vscsihbav204.gz A few observations from testing this version: # ./start_target.sh id=3 -files ../../zz_lun0 -v # lsscsi [0:0:0:0]diskLinuxscsi_debug 0004 /dev/sda [1:0:0:0]diskVirtualH VHD 0 /dev/sdb So id=3 doesn't look the target identifier. If not, what is it? Here is an attempt to fetch the Read Write Error Recovery mode page: # sdparm -p rw -vv /dev/sg1 inquiry cdb: 12 00 00 00 24 00 /dev/sg1: VirtualH VHD 0 mode sense (10) cdb: 5a 00 01 00 00 00 00 00 08 00 mode sense (10): Probably uninitialized data. Try to view as SCSI-1 non-extended sense: AdValid=0 Error class=0 Error code=0 Read write error recovery mode page [0x1] failed That implies a sense buffer full of zeroes. The debug output from start_target.sh associated with that attempt: SCSI cmd Lun=00 id=2D CDB=12 00 00 00 24 00 00 00 08 00 00 00 00 00 00 00 SCSI cmd Lun=00 id=2D completed, status=0 SCSI cmd Lun=00 id=2E CDB=5A 00 01 00 00 00 00 00 08 00 00 00 00 00 00 00 SCSI cmd Lun=00 id=2E completed, status=2 SCSI cmd Lun=00 id=2F CDB=03 00 00 00 FC 00 00 00 08 00 00 00 00 00 00 00 SCSI cmd Lun=00 id=2F completed, status=0 SCSI cmd Lun=00 id=30 CDB=00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 SCSI cmd Lun=00 id=30 completed, status=0 So that is an INQUIRY [expected], MODE SENSE(10) [expected], REQUEST SENSE [what, no autosense??] and TEST UNIT READY [ah oh, error recovery??] sequence. Perhaps you could examine the way scsi_debug (or most other LLDs) does autosense. This modern technique (used for about the last 12 years) relieves the scsi midlevel of having to send a follow up REQUEST SENSE. It would be easier to read those SCSI commands in the debug output if they were trimmed to their actual lengths (e.g. the INQUIRY is 12 00 00 00 24 00). Doug Gilbert - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 2/4] aacraid: expanded expose physical device code
+ if ((scsicmd-cmnd[0] == INQUIRY) (expose_physicals = 0)) {
+ u8 b;
+ u8 b1;
+ /* We can't expose disk devices because we can't
+ * tell whether they are the raw container drives
+ * or stand alone drives. If they have the removable
+ * bit set then we should expose them though.
+ */
+ b = (*(u8*)scsicmd-request_buffer)0x1f;
+ b1 = ((u8*)scsicmd-request_buffer)[1];
+ if (b == TYPE_TAPE || b == TYPE_WORM ||
+ b == TYPE_ROM || b==TYPE_MOD ||
+ b == TYPE_MEDIUM_CHANGER ||
+ (b == TYPE_DISK (b1 0x80))) {
+ scsicmd-result = DID_OK 16 |
+ COMMAND_COMPLETE 8;
This can't work at all. request_buffer is always a scatterlist these days.
Besides this implementation bug it's also not the wrong way to do it either.
Please just return -ENXIO in -slave_configure if sdev-type is not to
your liking instead of failing the INQUIRY command.
-
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: use lock per host instead of per device for shared queue tag host
The block layer uses lock to protect request queue. Every scsi device
has a unique request queue, and queue lock is the default lock in struct
request_queue. This is good for normal cases. But for a host with
shared queue tag (e.g. stex controllers), a queue lock per device means
the shared queue tag is not protected when multiple devices are accessed
at a same time. This patch is a simple fix for this situation by introducing
a host queue lock to protect shared queue tag. Without this patch we will
see various kernel panics (including the BUG() and kernel errors in
blk_queue_start_tag and blk_queue_end_tag of ll_rw_blk.c) when accessing
different devices simultaneously (e.g. copying big file from one device to
another in smp kernels).
This is against kernel 2.6.20-rc5.
Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
drivers/scsi/scsi_lib.c |2 +-
drivers/scsi/stex.c |2 ++
include/scsi/scsi_host.h |3 +++
3 files changed, 6 insertions(+), 1 deletion(-)
diff -purN a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
--- a/drivers/scsi/scsi_lib.c 2007-01-23 14:40:28.0 -0800
+++ b/drivers/scsi/scsi_lib.c 2007-01-23 14:46:43.0 -0800
@@ -1574,7 +1574,7 @@ struct request_queue *__scsi_alloc_queue
{
struct request_queue *q;
- q = blk_init_queue(request_fn, NULL);
+ q = blk_init_queue(request_fn, shost-req_q_lock);
if (!q)
return NULL;
diff -purN a/drivers/scsi/stex.c b/drivers/scsi/stex.c
--- a/drivers/scsi/stex.c 2007-01-23 14:40:28.0 -0800
+++ b/drivers/scsi/stex.c 2007-01-23 14:48:59.0 -0800
@@ -1254,6 +1254,8 @@ stex_probe(struct pci_dev *pdev, const s
if (err)
goto out_free_irq;
+ spin_lock_init(host-__req_q_lock);
+ host-req_q_lock = host-__req_q_lock;
err = scsi_init_shared_tag_map(host, host-can_queue);
if (err) {
printk(KERN_ERR DRV_NAME (%s): init shared queue failed\n,
diff -purN a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h
--- a/include/scsi/scsi_host.h 2007-01-23 14:40:29.0 -0800
+++ b/include/scsi/scsi_host.h 2007-01-23 14:57:04.0 -0800
@@ -508,6 +508,9 @@ struct Scsi_Host {
spinlock_t default_lock;
spinlock_t *host_lock;
+ spinlock_t __req_q_lock;
+ spinlock_t *req_q_lock;/* protect shared block queue tag */
+
struct mutexscan_mutex;/* serialize scanning activity */
struct list_headeh_cmd_q;
-
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
