Re: [PATCH] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices
Mark Lord wrote: For example, I think all existing ATAPI drives only speak 12-byte packet protocols, and so if we tell SCSI we're good for 16-byte, then won't the SCSI layer suddenly start sending us READ_16 and the like? Speaking strictly about the device, IDENTIFY PACKET DEVICE data page tells us whether the device supports 12-byte or 16-byte CDBs. No need to guess. Some host controllers only support 12-byte, but I think that most should support 16-byte. Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices
Tejun Heo wrote: SCSI always uses the smallest command it can use, so we're safe. Most other commands are issued directly from the userland and it's their responsibility not to feed disallowed commands to a device (or we need more advanced filter). Anyways, this has never been guaranteed because the limit is host wide. So, I'm for setting it to 16. Jeff, what do you think? Like I just noted in another email, the limit is really on the /device/ side. In theory the user could plug in a 16-byte ATAPI device and a 12-byte ATAPI device to the same host. We should be able to safely raise the limit to 16-byte for most host controllers. Note I said most. The bitch will be figuring out which host controllers do not like 16-byte CDBs. Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices
Mark Lord wrote: Tejun Heo wrote: Anyways, this has never been guaranteed because the limit is host wide. But until very very recently, host wide meant just a single device for libata. I was just assuming we did all of the fiddling to ensure a minimal value there for some real reason. But, yes, now we have PATA (2 drives per host), and PMP (many more drives per host), so just maxing out the limit seems sensible. No, we can't just assume that all host controller CDB FIFOs (if indeed that's the implementation) support 16-byte CDBs. Gotta do a controller-by-controller check. There are both /host/ and /device/ limits. Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] - export scsilun_to_int
James Bottomley wrote:
On Wed, 2007-01-31 at 15:54 -0700, Eric Moore wrote:
static int
+mptscsih_cmp_scsilun(struct scsi_lun * lun1, struct scsi_lun * lun2)
+{
+ int i;
+
+ for (i = 0; i 8 ; i++)
+ if (lun1-scsi_lun[i] != lun2-scsi_lun[i])
+ return 1;
+
+ return 0;
+}
what's wrong with
memcmp(lun1-scsi_lun, lun2-scsi_lun, 8)
rather than introducing a wrapper? The compiler can even optimise
memcmp for a fixed size nicely.
I would rather introduce a wrapper that calls memcmp()
That's why I have done in my scsilun tree (jgarzik/scsilun-2.6.git,
branches submit1, submit1 and hacking)
Jeff
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices
Jeff Garzik wrote: Mark Lord wrote: For example, I think all existing ATAPI drives only speak 12-byte packet protocols, and so if we tell SCSI we're good for 16-byte, then won't the SCSI layer suddenly start sending us READ_16 and the like? Speaking strictly about the device, IDENTIFY PACKET DEVICE data page tells us whether the device supports 12-byte or 16-byte CDBs. No need to guess. Some host controllers only support 12-byte, but I think that most should support 16-byte. Out of curiosity, does ATA controllers which don't allow 16byte CDB actually exist? It's transferred using PIO protocol anyway. -- tejun - 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] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices
Jeff Garzik wrote: Tejun Heo wrote: SCSI always uses the smallest command it can use, so we're safe. Most other commands are issued directly from the userland and it's their responsibility not to feed disallowed commands to a device (or we need more advanced filter). Anyways, this has never been guaranteed because the limit is host wide. So, I'm for setting it to 16. Jeff, what do you think? Like I just noted in another email, the limit is really on the /device/ side. In theory the user could plug in a 16-byte ATAPI device and a 12-byte ATAPI device to the same host. We should be able to safely raise the limit to 16-byte for most host controllers. Note I said most. The bitch will be figuring out which host controllers do not like 16-byte CDBs. Well, it's not any worse than what we're currently doing. We don't set host cdb len limit according to the host. We set it to the largest value among the attached devices. So, if there is a 12 byte only controller out there and if you connect 16 byte ATAPI device to it, you're screwed already and will continue to be screwed after the change. Note that raising host cdb limit to 16 doesn't make anybody issue 16 byte cdb to the device. The only unconditionally allowed 16 byte cdb is ATA_16 which is executed by libata SAT and thus doesn't pass through the host. -- tejun - 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] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices
Tejun Heo wrote: Jeff Garzik wrote: Mark Lord wrote: For example, I think all existing ATAPI drives only speak 12-byte packet protocols, and so if we tell SCSI we're good for 16-byte, then won't the SCSI layer suddenly start sending us READ_16 and the like? Speaking strictly about the device, IDENTIFY PACKET DEVICE data page tells us whether the device supports 12-byte or 16-byte CDBs. No need to guess. Some host controllers only support 12-byte, but I think that most should support 16-byte. Out of curiosity, does ATA controllers which don't allow 16byte CDB actually exist? It's transferred using PIO protocol anyway. That's why I think that most PATA controllers are likely safe, since it is just more twiddling signals directly to the device. We have to be more careful, ironically, with the smart controllers. They are more likely to keep the CDB contents in a FIFO or other silicon buffer somewhere, as temporary storage during a DMA - buffer - device transfer of the CDB contents. Any first-gen SATA-emulating-PATA controller is instantly under suspicion, because they are not truly twiddling signals but emulating such by building FIS's under the hood. Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Announce] sg3_utils-1.23 available
sg3_utils is a package of command line utilities for sending SCSI (and some ATA) commands to devices. This package targets the linux kernel (lk) 2.6 and lk 2.4 series. In the lk 2.6 series these utilities (except sgp_dd) can be used with any devices that support the SG_IO ioctl. Ported to FreeBSD, Tru64 and Windows (cygwin and mingw). This version adds sg_read_buffer and sg_write_buffer utilities. Cleans up command line interface of older utilities and all man pages have been reworked. Package synchronized with SPC-4 revision 8 and SBC-3 revision 8. Copy of ChangeLog below. For an overview of sg3_utils and downloads see this page: http://www.torque.net/sg/sg3_utils.html The sg_dd utility has its own page at: http://www.torque.net/sg/sg_dd.html The SG_IO ioctl is discussed at: http://www.torque.net/sg/sg_io.html A full changelog can be found at: http://www.torque.net/sg/p/sg3_utils.CHANGELOG A release announcement has been sent to freshmeat.net . Top of Changelog: Changelog for sg3_utils-1.23 [20070131] - sg_read_buffer: new utility - sg_write_buffer: new utility - sg_opcodes, sg_senddiag, sg_logs, sg_modes, sg_start, sg_inq, sg_turs, sg_readcap, sg_rbuf: add getopt_long() based cli; old and new cli selectable, new getopt_long cli is default - scripts: new subdirectory containing some bash scripts - add scripts/README file - sg_reassign: add '--hex' option for grown and primary lists - sg_rtpg: add '--raw' option - sg_lib.h, sg_cmds_basic.h + sg_cmds_extra.h: add C++ 'extern C ' wrappers - cleanup C code so it will compile as C++ - sg_lib: sync with spc4r08 - include inttypes.h, use PRId64 instead of %lld form - fix sg_get_sense_str() when empty sense buffer - win32 port: add Makefile.mingw + related support for MinGW - sg_cmds_extra: add sg_ll_read_buffer() and sg_ll_write_buffer() - sg_dd, sgp_dd, sgm_dd, sg_read: use lseek64() instead of llseek.c - sgm_dd: accept coe=n for interworking with sg_dd - sg_rdac: fix on non-linux ports - sg_ses: fix spurious warning in additional element status page - '-rr' option outputs a diagnostic page in binary to stdout - sg_opcodes: add command timeout descriptor support (spc4r08) - change linux specific pass through to generic pass through - sg_logs: add 'name=value' decoding for SAS specific lpage - examples+utils subdirectories: remove symlinks - synchronize man pages with usage messages - sg3_utils.spec: rework 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] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices
On Thu, 2007-02-01 at 04:54 -0500, Jeff Garzik wrote: Agreed... but that doesn't make it the /right/ thing to do ;-) The logic behind the current code, which limits to the maximum size allowed by an attached device on the port, is mainly to leverage the SCSI layer as a filter for bad CDB lengths. IOW, it's called being lazy ;-) But you're requesting code changes in the SCSI layer because of this incorrect usage. max_cdb is supposed to be the *host* limit. The mid layer finds out and respects device limits separately from this. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices
James Bottomley wrote: But you're requesting code changes in the SCSI layer because of this incorrect usage. max_cdb is supposed to be the *host* limit. The mid layer finds out and respects device limits separately from this. I never requested any such thing. Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] - export scsilun_to_int
On Wednesday, January 31, 2007 6:52 PM, James Bottomley wrote: what's wrong with memcmp(lun1-scsi_lun, lun2-scsi_lun, 8) rather than introducing a wrapper? The compiler can even optimise memcmp for a fixed size nicely. James Changed to using memcmp. This replaces the prevous patch. Signed-off-by: Eric Moore [EMAIL PROTECTED] diff -uarpN b/drivers/message/fusion/mptscsih.c a/drivers/message/fusion/mptscsih.c --- b/drivers/message/fusion/mptscsih.c 2007-01-27 19:09:00.0 -0700 +++ a/drivers/message/fusion/mptscsih.c 2007-02-01 10:09:24.0 -0700 @@ -1016,7 +1016,7 @@ mptscsih_search_running_cmds(MPT_SCSI_HO int ii; int max = hd-ioc-req_depth; struct scsi_cmnd *sc; - int lun; + struct scsi_lun lun; dsprintk((KERN_INFO MYNAM : search_running channel %d id %d lun %d max %d\n, vdevice-vtarget-channel, vdevice-vtarget-id, vdevice-lun, max)); @@ -1027,13 +1027,14 @@ mptscsih_search_running_cmds(MPT_SCSI_HO mf = (SCSIIORequest_t *)MPT_INDEX_2_MFPTR(hd-ioc, ii); if (mf == NULL) continue; - lun = scsilun_to_int((struct scsi_lun *)mf-LUN); - dsprintk(( search_running: found (sc=%p, mf = %p) chanel %d id %d, lun %d \n, - hd-ScsiLookup[ii], mf, mf-Bus, mf-TargetID, lun)); + int_to_scsilun(vdevice-lun, lun); if ((mf-Bus != vdevice-vtarget-channel) || (mf-TargetID != vdevice-vtarget-id) || - (lun != vdevice-lun)) + memcmp(lun.scsi_lun, mf-LUN, 8)) continue; + dsprintk(( search_running: found (sc=%p, mf = %p) + channel %d id %d, lun %d \n, hd-ScsiLookup[ii], + mf, mf-Bus, mf-TargetID, vdevice-lun)); /* Cleanup */ - 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/3] ipr: Use PCI-E reset API for new ipr adapter
Use a newly added PCI API to issue a PCI Fundamental reset
(warm reset) to a new ipr PCI-E adapter. Typically, the
ipr adapter uses the start BIST bit in config space to reset
an adapter. Issuing start BIST on this particular adapter
results in the PCI-E logic on the card losing sync, which
causes PCI-E errors, making the card unusable. The only reset
mechanism that exists on this hardware that does not have this
problem is PCI Fundamental reset (warm reset).
Signed-off-by: Brian King [EMAIL PROTECTED]
---
linux-2.6-bjking1/drivers/scsi/ipr.c | 61 ---
linux-2.6-bjking1/drivers/scsi/ipr.h |7 ++--
2 files changed, 61 insertions(+), 7 deletions(-)
diff -puN drivers/scsi/ipr.h~ipr_pci_reset6 drivers/scsi/ipr.h
--- linux-2.6/drivers/scsi/ipr.h~ipr_pci_reset6 2007-02-01 10:31:27.0
-0600
+++ linux-2.6-bjking1/drivers/scsi/ipr.h2007-02-01 10:31:27.0
-0600
@@ -37,8 +37,8 @@
/*
* Literals
*/
-#define IPR_DRIVER_VERSION 2.3.1
-#define IPR_DRIVER_DATE (January 23, 2007)
+#define IPR_DRIVER_VERSION 2.3.2
+#define IPR_DRIVER_DATE (January 26, 2007)
/*
* IPR_MAX_CMD_PER_LUN: This defines the maximum number of outstanding
@@ -182,6 +182,7 @@
#define IPR_WAIT_FOR_RESET_TIMEOUT (2 * HZ)
#define IPR_CHECK_FOR_RESET_TIMEOUT(HZ / 10)
#define IPR_WAIT_FOR_BIST_TIMEOUT (2 * HZ)
+#define IPR_PCI_RESET_TIMEOUT (HZ / 2)
#define IPR_DUMP_TIMEOUT (15 * HZ)
/*
@@ -1058,6 +1059,7 @@ struct ipr_ioa_cfg {
u8 allow_cmds:1;
u8 allow_ml_add_del:1;
u8 needs_hard_reset:1;
+ u8 needs_warm_reset:1;
enum ipr_cache_state cache_state;
u16 type; /* CCIN of the card */
@@ -1150,6 +1152,7 @@ struct ipr_ioa_cfg {
struct pci_pool *ipr_cmd_pool;
struct ipr_cmnd *reset_cmd;
+ int (*reset) (struct ipr_cmnd *);
struct ata_host ata_host;
char ipr_cmd_label[8];
diff -puN drivers/scsi/ipr.c~ipr_pci_reset6 drivers/scsi/ipr.c
--- linux-2.6/drivers/scsi/ipr.c~ipr_pci_reset6 2007-02-01 10:31:27.0
-0600
+++ linux-2.6-bjking1/drivers/scsi/ipr.c2007-02-01 10:31:27.0
-0600
@@ -6397,6 +6397,48 @@ static int ipr_reset_start_bist(struct i
}
/**
+ * ipr_reset_slot_reset_done - Clear PCI reset to the adapter
+ * @ipr_cmd: ipr command struct
+ *
+ * Description: This clears PCI reset to the adapter and delays two seconds.
+ *
+ * Return value:
+ * IPR_RC_JOB_RETURN
+ **/
+static int ipr_reset_slot_reset_done(struct ipr_cmnd *ipr_cmd)
+{
+ ENTER;
+ pci_set_pcie_reset_state(ipr_cmd-ioa_cfg-pdev, pci_reset_normal);
+ ipr_cmd-job_step = ipr_reset_bist_done;
+ ipr_reset_start_timer(ipr_cmd, IPR_WAIT_FOR_BIST_TIMEOUT);
+ LEAVE;
+ return IPR_RC_JOB_RETURN;
+}
+
+/**
+ * ipr_reset_slot_reset - Reset the PCI slot of the adapter.
+ * @ipr_cmd: ipr command struct
+ *
+ * Description: This asserts PCI reset to the adapter.
+ *
+ * Return value:
+ * IPR_RC_JOB_RETURN
+ **/
+static int ipr_reset_slot_reset(struct ipr_cmnd *ipr_cmd)
+{
+ struct ipr_ioa_cfg *ioa_cfg = ipr_cmd-ioa_cfg;
+ struct pci_dev *pdev = ioa_cfg-pdev;
+
+ ENTER;
+ pci_block_user_cfg_access(pdev);
+ pci_set_pcie_reset_state(pdev, pci_reset_pcie_warm_reset);
+ ipr_cmd-job_step = ipr_reset_slot_reset_done;
+ ipr_reset_start_timer(ipr_cmd, IPR_PCI_RESET_TIMEOUT);
+ LEAVE;
+ return IPR_RC_JOB_RETURN;
+}
+
+/**
* ipr_reset_allowed - Query whether or not IOA can be reset
* @ioa_cfg: ioa config struct
*
@@ -6435,7 +6477,7 @@ static int ipr_reset_wait_to_start_bist(
ipr_cmd-u.time_left -= IPR_CHECK_FOR_RESET_TIMEOUT;
ipr_reset_start_timer(ipr_cmd, IPR_CHECK_FOR_RESET_TIMEOUT);
} else {
- ipr_cmd-job_step = ipr_reset_start_bist;
+ ipr_cmd-job_step = ioa_cfg-reset;
rc = IPR_RC_JOB_CONTINUE;
}
@@ -6468,7 +6510,7 @@ static int ipr_reset_alert(struct ipr_cm
writel(IPR_UPROCI_RESET_ALERT,
ioa_cfg-regs.set_uproc_interrupt_reg);
ipr_cmd-job_step = ipr_reset_wait_to_start_bist;
} else {
- ipr_cmd-job_step = ipr_reset_start_bist;
+ ipr_cmd-job_step = ioa_cfg-reset;
}
ipr_cmd-u.time_left = IPR_WAIT_FOR_RESET_TIMEOUT;
@@ -6748,8 +6790,11 @@ static pci_ers_result_t ipr_pci_slot_res
struct ipr_ioa_cfg *ioa_cfg = pci_get_drvdata(pdev);
spin_lock_irqsave(ioa_cfg-host-host_lock, flags);
- _ipr_initiate_ioa_reset(ioa_cfg, ipr_reset_restore_cfg_space,
-IPR_SHUTDOWN_NONE);
+ if (ioa_cfg-needs_warm_reset)
+ ipr_initiate_ioa_reset(ioa_cfg, IPR_SHUTDOWN_NONE);
+ else
+ _ipr_initiate_ioa_reset(ioa_cfg, ipr_reset_restore_cfg_space,
+
[PATCH 1/3] pci: New PCI-E reset API
Adds a new API which can be used to issue various types
of PCI-E reset, including PCI-E warm reset and PCI-E hot reset.
This is needed for an ipr PCI-E adapter which does not properly
implement BIST. Running BIST on this adapter results in PCI-E
errors. The only reliable reset mechanism that exists on this
hardware is PCI Fundamental reset (warm reset). Since driving
this type of reset is architecture unique, this provides the
necessary hooks for architectures to add this support.
Signed-off-by: Brian King [EMAIL PROTECTED]
---
linux-2.6-bjking1/drivers/pci/pci.c | 29 +
linux-2.6-bjking1/include/linux/pci.h | 14 ++
2 files changed, 43 insertions(+)
diff -puN drivers/pci/pci.c~pci_pci_reset_api drivers/pci/pci.c
--- linux-2.6/drivers/pci/pci.c~pci_pci_reset_api 2007-01-30
12:48:54.0 -0600
+++ linux-2.6-bjking1/drivers/pci/pci.c 2007-01-30 12:48:54.0 -0600
@@ -791,6 +791,34 @@ pci_disable_device(struct pci_dev *dev)
}
/**
+ * pcibios_set_pcie_reset_state - set reset state for device dev
+ * @dev: the PCI-E device reset
+ * @state: Reset state to enter into
+ *
+ *
+ * Sets the PCI-E reset state for the device. This is the default
+ * implementation. Architecture implementations can override this.
+ */
+int __attribute__ ((weak)) pcibios_set_pcie_reset_state(struct pci_dev *dev,
+ enum pcie_reset_state
state)
+{
+ return -EINVAL;
+}
+
+/**
+ * pci_set_pcie_reset_state - set reset state for device dev
+ * @dev: the PCI-E device reset
+ * @state: Reset state to enter into
+ *
+ *
+ * Sets the PCI reset state for the device.
+ */
+int pci_set_pcie_reset_state(struct pci_dev *dev, enum pcie_reset_state state)
+{
+ return pcibios_set_pcie_reset_state(dev, state);
+}
+
+/**
* pci_enable_wake - enable device to generate PME# when suspended
* @dev: - PCI device to operate on
* @state: - Current state of device.
@@ -1210,6 +1238,7 @@ EXPORT_SYMBOL(pci_set_power_state);
EXPORT_SYMBOL(pci_save_state);
EXPORT_SYMBOL(pci_restore_state);
EXPORT_SYMBOL(pci_enable_wake);
+EXPORT_SYMBOL_GPL(pci_set_pcie_reset_state);
/* Quirk info */
diff -puN include/linux/pci.h~pci_pci_reset_api include/linux/pci.h
--- linux-2.6/include/linux/pci.h~pci_pci_reset_api 2007-01-30
12:48:54.0 -0600
+++ linux-2.6-bjking1/include/linux/pci.h 2007-01-30 12:48:54.0
-0600
@@ -96,6 +96,19 @@ enum pci_channel_state {
pci_channel_io_perm_failure = (__force pci_channel_state_t) 3,
};
+typedef unsigned int __bitwise pcie_reset_state_t;
+
+enum pcie_reset_state {
+ /* Reset is NOT asserted (Use to deassert reset) */
+ pci_reset_normal = (__force pcie_reset_state_t) 1,
+
+ /* Use #PERST to reset PCI-E device */
+ pci_reset_pcie_warm_reset = (__force pcie_reset_state_t) 2,
+
+ /* Use PCI-E Hot Reset to reset device */
+ pci_reset_pcie_hot_reset = (__force pcie_reset_state_t) 3
+};
+
typedef unsigned short __bitwise pci_bus_flags_t;
enum pci_bus_flags {
PCI_BUS_FLAGS_NO_MSI = (__force pci_bus_flags_t) 1,
@@ -523,6 +536,7 @@ int __must_check pci_enable_device(struc
int __must_check pci_enable_device_bars(struct pci_dev *dev, int mask);
void pci_disable_device(struct pci_dev *dev);
void pci_set_master(struct pci_dev *dev);
+int pci_set_pcie_reset_state(struct pci_dev *dev, enum pcie_reset_state state);
#define HAVE_PCI_SET_MWI
int __must_check pci_set_mwi(struct pci_dev *dev);
void pci_clear_mwi(struct pci_dev *dev);
_
-
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] - export scsilun_to_int
Eric Moore wrote: On Wednesday, January 31, 2007 6:52 PM, James Bottomley wrote: what's wrong with memcmp(lun1-scsi_lun, lun2-scsi_lun, 8) rather than introducing a wrapper? The compiler can even optimise memcmp for a fixed size nicely. James Changed to using memcmp. This replaces the prevous patch. Signed-off-by: Eric Moore [EMAIL PROTECTED] IMO a wrapper is better. memcmp() is not type-safe nor type-aware, and we have already created a type for SCSI LUNs. Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] pci: New PCI-E reset API
On Thu, Feb 01, 2007 at 11:30:21AM -0600, Brian King wrote: Adds a new API which can be used to issue various types of PCI-E reset, including PCI-E warm reset and PCI-E hot reset. This is needed for an ipr PCI-E adapter which does not properly implement BIST. Running BIST on this adapter results in PCI-E errors. The only reliable reset mechanism that exists on this hardware is PCI Fundamental reset (warm reset). Since driving this type of reset is architecture unique, this provides the necessary hooks for architectures to add this support. A few points ... - When doing a warm reset, you reset the entire device not just the function (== pci_dev) that gets passed in. How happy are drivers for the other functions going to be about this? - You've missed the requirement: To allow components to perform internal initialization, system software must wait for at least 100 ms from the end of a Conventional Reset of one or more devices before it is permitted to issue Configuration Requests to those devices. To fix this, we need to call pci_block_user_cfg_access() before calling the pcibios function, then msleep(100) after calling it, then call pci_unblock_user_cfg_access(). - There's no attempt to support either cold or function-level reset in this patch. I suspect the Right Way of handling hot/warm/cold reset is going to be some kind of integration with error handling. This driver understands about slots being different from functions, and has the ability to notify drivers of other functions that a reset is happening. To a certain extent, what's going on with IPR here *is* an error condition, it's just that we can recover from it with a warm reset rather than a hot reset. - 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 1/3] pci: New PCI-E reset API
Matthew Wilcox wrote: On Thu, Feb 01, 2007 at 11:30:21AM -0600, Brian King wrote: Adds a new API which can be used to issue various types of PCI-E reset, including PCI-E warm reset and PCI-E hot reset. This is needed for an ipr PCI-E adapter which does not properly implement BIST. Running BIST on this adapter results in PCI-E errors. The only reliable reset mechanism that exists on this hardware is PCI Fundamental reset (warm reset). Since driving this type of reset is architecture unique, this provides the necessary hooks for architectures to add this support. A few points ... - When doing a warm reset, you reset the entire device not just the function (== pci_dev) that gets passed in. How happy are drivers for the other functions going to be about this? I guess I don't see how a warm reset could be issued to a single function of a PCI device. I would argue that for a multi-function device, you would have to use function level reset. - You've missed the requirement: To allow components to perform internal initialization, system software must wait for at least 100 ms from the end of a Conventional Reset of one or more devices before it is permitted to issue Configuration Requests to those devices. To fix this, we need to call pci_block_user_cfg_access() before calling the pcibios function, then msleep(100) after calling it, then call pci_unblock_user_cfg_access(). What I've done is to provide a very low-level API that can be used to accomplish this. In my implementation, the ipr driver is the one doing all the required delays and calling pci_block_user_cfg_access, since it already was doing that in order to run BIST on the adapter. - There's no attempt to support either cold or function-level reset in this patch. Correct. I had no requirement to implement this. It can always be added if there is a need. A function level reset can be performed by simply writing a bit in config space, so *technically* we wouldn't need an API to do that for us, but it could certainly be added here. I suspect the Right Way of handling hot/warm/cold reset is going to be some kind of integration with error handling. This driver understands about slots being different from functions, and has the ability to notify drivers of other functions that a reset is happening. Perhaps. It would require a way for the adapter device driver to indicate what type of reset(s) will work for a particular pci device. It would also require a method for a device driver to invoke a reset, which does not currently exist today. I think it would be the first case of the device driver invoking pci error recovery, so I'm not sure how difficult that would be to do with the current code. I actually thought this API might be used by PCI error recovery code, since it may need to perform these sorts of functions. CC'ing Linas Vepstas since he wrote the powerpc pci recovery code. Brian -- Brian King eServer Storage I/O IBM Linux Technology Center - 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: [Bugme-new] [Bug 7919] New: Tape dies if wrong block size used
On Thu, 1 Feb 2007 15:34:29 -0800 [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=7919 Summary: Tape dies if wrong block size used Kernel Version: 2.6.20-rc5 Status: NEW Severity: normal Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Most recent kernel where this bug did *NOT* occur: 2.6.17.14 Other Kernels Tested and Results: OK 2.6.15.7 OK 2.6.16.37 OK 2.6.17.14 BAD 2.6.18.6 BAD 2.6.18-1.2869.fc6 BAD 2.6.19.2 + BAD 2.6.20-rc5 NOTE: 2.6.18-1.2869.fc6 is a Fedora modified kernel, all others are from kernel.org Distribution: Fedora Hardware Environment: i386 ArchI386 ModelDell Poweredge 1300 ProcessorPentium III (Coppermine) 697.929 Mhz. SCSIAdaptec AHA-2940U/UW/D / AIC-7881U Disks3 QUANTUM ATLAS V 9 WLS in RAID 5 software raid attached to adaptech card above TapeHP C1537A attached to adaptech card above Software Environment: tar and mt Problem Description: I usually specify a tape block size, such as 'mt setblk 4096'. If I access the tape drive with the wrong tape block size, for instance 'tar -cvf /dev/tape foo', the screen fills with kernel errors. If I use the correct block size, as in 'tar -b 8 -cvf /dev/tape foo', it works fine. If I use the wrong block size I have to reboot to make the tape drive respond again. I've seen this problem on three systems with identical SCSI cards and different tape drives, so that makes me think it's the AIC7XXX driver. I've tested with several kernels to try and isolate when this problem was introduced. More details below. Interestingly, my main testing system is running software raid from the same scsi card with no problems, so this seems specific to tape drives. The other machine I've seen this on had a separate raid card, so you can't blame it on my software raid setup. Steps to reproduce: Get a Adaptec AHA-2940U/UW/D / AIC-7881U card and a tape drive, install a recent kernel set the tape block size - mt setblk 4096 read from or write to tape using wrong block size - tar -b 7 -cvf /dev/tape foo --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - 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] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices
James Bottomley wrote: On Thu, 2007-02-01 at 04:54 -0500, Jeff Garzik wrote: Agreed... but that doesn't make it the /right/ thing to do ;-) The logic behind the current code, which limits to the maximum size allowed by an attached device on the port, is mainly to leverage the SCSI layer as a filter for bad CDB lengths. IOW, it's called being lazy ;-) But you're requesting code changes in the SCSI layer because of this incorrect usage. max_cdb is supposed to be the *host* limit. The mid layer finds out and respects device limits separately from this. To be more pedantic: actual_max_cdb = min(MAX_COMMAND_SIZE, host_limit) Since the host is a bridge, that could be a limit on near side (i.e. PCI (unlikely)) or the outer side (i.e. transport initiator (port)). In modern HBAs the host_limit is likely to be greater than 16, to allow for advanced SBC and OSD commands. However currently MAX_COMMAND_SIZE (defined in scsi/scsi_cmnd.h) is 16. It is the ATAPI _transport_ that has the 12 byte cdb limit *** (at least according to MMC-5 rev Annex A; is S-ATAPI any better?). Other MMC transports referred to in MMC-5 are SPI, SBP(IEEE 1394) and USB mass storage; and no mention is made of cdb length limits for them. Since ATAPI is the dominant transport for cd/dvd drives, MMC doesn't define any commands over 12 bytes in length, but both SPC (which MMC should honour) and SSC-3 (think tape drives, ATAPI connected) do. My point is that the linux block layer and scsi mid level should get out of the business of putting hard limits place. Why? Since kernel limits are at best necessary but not sufficient, the upper layers still need to be able to cope with errors associated with that limit. So why have the limit? Does the kernel do analysis to find out whether a USB connected DVD drive has a USB to ATAPI bridge externally? I don't think so. There is a role to fetch information that may act as a guide when a ULD has a choice of commands to build (e.g. sd deciding between READ(10) and READ(16)). Let the cdb size bottleneck (or whatever) report an error and upper layers that are impacted, including user space programs, can act accordingly. If the kernel really wants to offload complexity to the user space, the kernel needs to get out of the business of trying to foresee errors. It needs to get better at coping with errors and if possible adapting its behaviour. *** not the host nor the device 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] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices
Douglas Gilbert wrote: It is the ATAPI _transport_ that has the 12 byte cdb limit *** (at least according to MMC-5 rev Annex A; is S-ATAPI any better?). Then the spec is wrong. 1) The transport does not limit the CDB size. 2) The ATAPI device limits the CDB size, and it exports this limit via IDENTIFY PACKET DEVICE. It can be either 12 or 16 bytes. 3) In some rare cases, the host controller silicon may limit CDB size. Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scsi_lib.c: continue after MEDIUM_ERROR
James Bottomley wrote:
On Tue, 2007-01-30 at 19:47 -0500, Mark Lord wrote:
Kernels since about 2.6.16 or so have been broken in this regard.
They complete the good sectors before the error,
and then fail the entire remaining portions of the request.
What was the commit that introduced the change? ... I have a vague
memory of it being deliberate.
I believe you made the first change in response to my prodding at the time,
when libata was not returning valid sense data (no LBA) for media errors.
The SCSI EH handling of that was rather poor at the time,
and so having it not retry the remaining sectors was actually
a very good fix at the time.
But now, libata *does* return valid sense data for LBA/DMA drives,
and the workaround from circa 2.6.16 is no longer the best we can do.
Now that we know which sector failed, we ought to be able to skip
over it, and continue with the rest of the merged request.
One thing that could be even better than the patch below,
would be to have it perhaps skip the entire bio that includes
the failed sector, rather than only the bad sector itself.
I think doing that might address most concerns expressed here.
Have you got an alternate suggestion, James?
..
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
diff -u --recursive --new-file --exclude-from=linux_17//Documentation/dontdiff
old/drivers/scsi/scsi_lib.c linux/drivers/scsi/scsi_lib.c
--- old/drivers/scsi/scsi_lib.c 2007-01-30 13:58:05.0 -0500
+++ linux/drivers/scsi/scsi_lib.c 2007-01-30 18:30:01.0 -0500
@@ -865,6 +865,12 @@
*/
if (sense_valid !sense_deferred) {
switch (sshdr.sense_key) {
+ case MEDIUM_ERROR:
+ // Bad sector. Fail it, and then continue the rest of
the request:
+ if (scsi_end_request(cmd, 0, cmd-device-sector_size,
1) == NULL) {
The sense key may have come with additional information I think we want
to parse that (if it exists) rather than just blindly failing the first
sector of the request.
+ cmd-retries = 0;// go around again..
+ return;
+ }
This would drop through to the UNIT_ATTENTION case if scsi_end_request()
fails ... I don't think that's correct.
case UNIT_ATTENTION:
if (cmd-device-removable) {
/* Detected disc change. Set a bit
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scsi_lib.c: continue after MEDIUM_ERROR
James Bottomley wrote: On Thu, 2007-02-01 at 15:02 -0500, Mark Lord wrote: .. One thing that could be even better than the patch below, would be to have it perhaps skip the entire bio that includes the failed sector, rather than only the bad sector itself. Er ... define skip over the bio. A bio is simply a block representation for a bunch of sg elements coming in to the elevator. Exactly. Or rather, a block of sg_elements from a single point of request, is it not? Mostly what we see in SCSI is a single bio per request, so skipping the bio is really the current behaviour (to fail the rest of the request). Very good. That's what it's supposed to do. But if each request contained only a single bio, then all of Jens' work on IO scheduling would be for nothing, n'est-ce pas? In the case where a request consists of multiple bio's which have been merged under a single request struct, we really should give at least one attempt to each bio. This way, in most cases, only the process that requested the failed sector(s) will see an error, not the innocent victims that happened to get merged onto the end. Which could be very critical stuff (or not -- it could be quite random). So the time factor works out to one disk I/O timeout per failed bio. That's what would have happened with the NOP scheduler anyway. On the sytems I'm working with, I don't see huge numbers of bad sectors. What they tend to show is just one or two bad sectors, widely scattered. So: I think doing that might address most concerns expressed here. Have you got an alternate suggestion, James? Cheers - 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: [BUG] Unable to handle kernel NULL pointer dereference...as_move_to_dispatch+0x11/0x135
On Mon, 22 Jan 2007 10:35:10 -0800 Andrew Vasquez [EMAIL PROTECTED] wrote: All, We've been trying to track down a nagging regression seen during some port-disable/enable testing. The problem occurs anywhere from 20 minutes to 120 minutes of testing under very minimal I/O load: [ 1143.890598] Unable to handle kernel NULL pointer dereference at 0028 RIP: [ 1143.896087] [802ed04f] as_move_to_dispatch+0x11/0x135 [ 1143.904574] PGD 120ba067 PUD 31e8c067 PMD 0 [ 1143.908895] Oops: [1] SMP [ 1143.912065] CPU 1 [ 1143.914092] Modules linked in: qla2xxx scsi_transport_fc [ 1143.919453] Pid: 8362, comm: dt Not tainted 2.6.19 #39 [ 1143.924588] RIP: 0010:[802ed04f] [802ed04f] as_move_to_dispatch+0x11/0x135 [ 1143.933300] RSP: 0018:8100021f7cf0 EFLAGS: 00010046 [ 1143.938610] RAX: RBX: 8100261392f0 RCX: [ 1143.945736] RDX: RSI: RDI: 8100261392f0 [ 1143.952865] RBP: R08: 804d0928 R09: 8100351a96e0 [ 1143.959992] R10: 8100351a96e0 R11: R12: [ 1143.967118] R13: R14: 0282 R15: 0001 [ 1143.974248] FS: () GS:8100021c5930() knlGS: [ 1143.982327] CS: 0010 DS: ES: CR0: 8005003b [ 1143.988070] CR2: 0028 CR3: 3493b000 CR4: 06e0 [ 1143.995198] Process dt (pid: 8362, threadinfo 8100207a2000, task 810023d86840) [ 1144.003103] Stack: 8100261392f0 0001 [ 1144.011183] 802ed591 810035795990 [ 1144.018640] 81000f11b3f8 810035795990 810035795990 802e53d6 [ 1144.025906] Call Trace: [ 1144.028548] IRQ [802ed591] as_dispatch_request+0x39d/0x3aa [ 1144.035274] [802e53d6] elv_next_request+0x45/0x151 [ 1144.041015] [8037b3cf] scsi_request_fn+0x7a/0x375 [ 1144.046667] [802e8fa0] blk_run_queue+0x42/0x74 [ 1144.052062] [8037b2bc] scsi_next_command+0x2d/0x39 [ 1144.057805] [8037b85b] scsi_end_request+0xc0/0xce [ 1144.063460] [8037ba03] scsi_io_completion+0x149/0x351 [ 1144.069464] [8038aad6] sd_rw_intr+0x247/0x256 [ 1144.074770] [80376b92] scsi_finish_command+0x88/0x8d [ 1144.080686] [8037c25e] scsi_softirq_done+0xe7/0xef [ 1144.086429] [802e614c] blk_done_softirq+0x63/0x71 [ 1144.092082] [80226487] __do_softirq+0x51/0xbd [ 1144.097394] [8020a88c] call_softirq+0x1c/0x28 [ 1144.102701] [8020bffa] do_softirq+0x2e/0x94 [ 1144.107836] [8020c10e] do_IRQ+0xae/0xc8 [ 1144.112625] [80209c81] ret_from_intr+0x0/0xb [ 1144.117845] EOI [8027dfad] __bio_add_page+0x1b8/0x1bf [ 1144.124135] [8027ecb6] blkdev_direct_IO+0x2c9/0x420 [ 1144.129964] [8021a1f4] __activate_task+0x2d/0x3f [ 1144.135537] [8040df0d] _spin_unlock_irq+0x6/0x9 [ 1144.141024] [80241d86] generic_file_direct_IO+0xa6/0xe8 [ 1144.147196] [80219efe] __wake_up_common+0x42/0x6c [ 1144.152852] [80242515] generic_file_aio_read+0xcc/0x19d [ 1144.159029] [8025d7cd] do_sync_read+0xc8/0x10b [ 1144.164426] [8023343c] autoremove_wake_function+0x0/0x2e [ 1144.170684] [8040df0d] _spin_unlock_irq+0x6/0x9 [ 1144.176166] [8025c516] do_filp_open+0x2d/0x3d [ 1144.181480] [80259876] poison_obj+0x35/0x44 [ 1144.186620] [8025e1c0] vfs_read+0xac/0x14f [ 1144.191668] [8025e322] sys_read+0x45/0x6e [ 1144.196630] [8020976e] system_call+0x7e/0x83 [ 1144.201852] ... Basically what is happening from the FC side is the initiator executes a simple dt test: dt of=/dev/raw/raw1 procs=8 oncerr=abort bs=16k disable=stats limit=2m passes=100 pattern=iot dlimit=2048 against a single lun (a very basic Windows target mode driver). During the test a port-enable, port-disable script is running agains the switch's port that is connected to the target (this occurs every sixty seconds (for a disabled duration of 2 seconds). Additionally, the target itself is set to LOGO (logout) or drop off the topology every 30 seconds. I don't understand what effect the port-enable/port-disable has upon the system. Will it cause I/O errors, or what? This test runs fine up to 2.6.19. One thing we did in there was to give direct-io-against-blockdevs some special-case bio-preparation
