Re: [PATCH update] SCSI: update Kconfig help text to indicate SCSI core's widespread usage

2007-09-14 Thread Stefan Richter
FUJITA Tomonori wrote:
> On Fri, 14 Sep 2007 23:14:21 +0200 (CEST)
> Stefan Richter <[EMAIL PROTECTED]> wrote:
...
>> And one more update:
>> There is SAS too,
...
>> +  You need it
>> +  - for classic parallel SCSI hardware,
>> +  - for newer SCSI transports such as Fibre Channel, FireWire storage,
>> +SAS, or iSCSI,
> 
> There is SRP too.

I think I'll rewrite it as "for newer SCSI transports such as FireWire
storage."  ;-)

If SRP was in, can 'such as' be omitted?  "for newer SCSI transports
(Fibre Channel, FireWire storage, iSCSI, SAS, SRP),"  Or would be "for
newer SCSI transports such as Fibre Channel, FireWire storage, iSCSI,
SAS, and more," be OK?
-- 
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: 2.6.23-rc4-mm1

2007-09-14 Thread Paul Jackson
FUJITA Tomonori wrote:
> Can you try this patch (against 2.6.23-rc4-mm1)?
> 
> >From 592bd2049cb3e6e1f1dde7cf631879f26ddffeaa Mon Sep 17 00:00:00 2001
> From: FUJITA Tomonori <[EMAIL PROTECTED]>
> Date: Mon, 10 Sep 2007 04:17:13 +0100
> Subject: [PATCH] qla1280: sg chaining fixes
> 
> Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
> ---
>  drivers/scsi/qla1280.c |5 -
>  1 files changed, 4 insertions(+), 1 deletions(-)

This patch works for me.

I was getting the scsi errors reported earlier in
this thread, running 2.6.23-rc4-mm1 on one of our
big SGI Altix systems.

Applying this patch fixed it, so far as I can tell,
which is to say my system boots cleanly once again.

Thanks.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401
-
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] MAINTAINERS : mpt fusion mailing list change

2007-09-14 Thread Eric Moore
Mailing list changed. The former list at [EMAIL PROTECTED] is no
longer in service. Please use the new email provided listed in this patch.

Signed-off-by: Eric Moore <[EMAIL PROTECTED]>

diff -uarpN b/MAINTAINERS a/MAINTAINERS
--- b/MAINTAINERS   2007-08-15 16:33:58.0 -0600
+++ a/MAINTAINERS   2007-09-14 19:20:34.0 -0600
@@ -2375,7 +2375,7 @@ LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
 P: Eric Moore
 M: [EMAIL PROTECTED]
 M: [EMAIL PROTECTED]
-L: [EMAIL PROTECTED]
+L: [EMAIL PROTECTED]
 L: linux-scsi@vger.kernel.org
 W: http://www.lsilogic.com/support
 S: Supported
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 8/8] mpt fusion: bump version to 3.04.06

2007-09-14 Thread Eric Moore
bump version

Signed-off-by: Eric Moore <[EMAIL PROTECTED]>

diff -uarpN b/drivers/message/fusion/mptbase.h 
a/drivers/message/fusion/mptbase.h
--- b/drivers/message/fusion/mptbase.h  2007-09-13 14:30:29.0 -0600
+++ a/drivers/message/fusion/mptbase.h  2007-09-14 17:52:30.0 -0600
@@ -75,8 +75,8 @@
 #define COPYRIGHT  "Copyright (c) 1999-2007 " MODULEAUTHOR
 #endif
 
-#define MPT_LINUX_VERSION_COMMON   "3.04.05"
-#define MPT_LINUX_PACKAGE_NAME "@(#)mptlinux-3.04.05"
+#define MPT_LINUX_VERSION_COMMON   "3.04.06"
+#define MPT_LINUX_PACKAGE_NAME "@(#)mptlinux-3.04.06"
 #define WHAT_MAGIC_STRING  "@" "(" "#" ")"
 
 #define show_mptmod_ver(s,ver)  \
-
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 7/8] mpt fusion: Kconfig cleanup

2007-09-14 Thread Eric Moore
Adding 949X, 949E, and 1078 to Kconfig.   Adding "depends on FUSION" required 
in the FUSION_LOGGING section, and fixing a spelling error.

Signed-off-by: Eric Moore <[EMAIL PROTECTED]>

diff -uarpN b/drivers/message/fusion/Kconfig a/drivers/message/fusion/Kconfig
--- b/drivers/message/fusion/Kconfig2007-09-13 14:30:29.0 -0600
+++ a/drivers/message/fusion/Kconfig2007-09-14 17:49:46.0 -0600
@@ -41,6 +41,8 @@ config FUSION_FC
  LSIFC929
  LSIFC929X
  LSIFC929XL
+ LSIFC949X
+ LSIFC949E
  Brocade FC 410/420
 
 config FUSION_SAS
@@ -56,6 +58,7 @@ config FUSION_SAS
  LSISAS1068
  LSISAS1064E
  LSISAS1068E
+ LSISAS1078
 
 config FUSION_MAX_SGE
int "Maximum number of scatter gather entries (16 - 128)"
@@ -106,7 +109,6 @@ config FUSION_LAN
 
 config FUSION_LOGGING
bool "Fusion MPT logging facility"
-   depends on FUSION
---help---
  This turns on a logging facility that can be used to debug a number
  of Fusion MPT related problems.
@@ -115,7 +117,7 @@ config FUSION_LOGGING
 
  echo [level] > /sys/class/scsi_host/host#/debug_level
 
- There are various debug levels that an be found in the source:
+ There are various debug levels that can be found in the source:
  file:drivers/message/fusion/mptdebug.h
 
 endif # FUSION
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 6/8] mpt fusion: removing Dell copyright

2007-09-14 Thread Eric Moore
Some other vender has concerns over this copyright, and Dell has approved 
removing it.

Signed-off-by: Eric Moore <[EMAIL PROTECTED]>

diff -uarpN b/drivers/message/fusion/mptsas.c a/drivers/message/fusion/mptsas.c
--- b/drivers/message/fusion/mptsas.c   2007-09-14 17:09:59.0 -0600
+++ a/drivers/message/fusion/mptsas.c   2007-09-14 17:48:07.0 -0600
@@ -5,7 +5,6 @@
  *
  *  Copyright (c) 1999-2007 LSI Corporation
  *  (mailto:[EMAIL PROTECTED])
- *  Copyright (c) 2005-2007 Dell
  */
 /*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
 /*
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 5/8] mpt fusion: removing references to hd->ioc

2007-09-14 Thread Eric Moore
Cleaning up code by accesing the ioc pointer directly instead of via hd->ioc.  
In the future, most data members of struct MPT_SCSI_HOST will be either deleted 
or moved to struct MPT_ADAPTER.

Signed-off-by: Eric Moore <[EMAIL PROTECTED]>

diff -uarpN b/drivers/message/fusion/mptfc.c a/drivers/message/fusion/mptfc.c
--- b/drivers/message/fusion/mptfc.c2007-09-14 16:39:53.0 -0600
+++ a/drivers/message/fusion/mptfc.c2007-09-14 17:11:51.0 -0600
@@ -194,12 +194,14 @@ mptfc_block_error_handler(struct scsi_cm
struct fc_rport *rport = starget_to_rport(scsi_target(sdev));
unsigned long   flags;
int ready;
+   MPT_ADAPTER *ioc;
 
hd = (MPT_SCSI_HOST *) SCpnt->device->host->hostdata;
+   ioc = hd->ioc;
spin_lock_irqsave(shost->host_lock, flags);
while ((ready = fc_remote_port_chkready(rport) >> 16) == DID_IMM_RETRY) 
{
spin_unlock_irqrestore(shost->host_lock, flags);
-   dfcprintk (hd->ioc, printk(MYIOC_s_DEBUG_FMT
+   dfcprintk (ioc, printk(MYIOC_s_DEBUG_FMT
"mptfc_block_error_handler.%d: %d:%d, port status is "
"DID_IMM_RETRY, deferring %s recovery.\n",
((MPT_SCSI_HOST *) shost->hostdata)->ioc->name,
@@ -211,7 +213,7 @@ mptfc_block_error_handler(struct scsi_cm
spin_unlock_irqrestore(shost->host_lock, flags);
 
if (ready == DID_NO_CONNECT || !SCpnt->device->hostdata) {
-   dfcprintk (hd->ioc, printk(MYIOC_s_DEBUG_FMT
+   dfcprintk (ioc, printk(MYIOC_s_DEBUG_FMT
"%s.%d: %d:%d, failing recovery, "
"port state %d, vdevice %p.\n", caller,
((MPT_SCSI_HOST *) shost->hostdata)->ioc->name,
@@ -220,7 +222,7 @@ mptfc_block_error_handler(struct scsi_cm
SCpnt->device->hostdata));
return FAILED;
}
-   dfcprintk (hd->ioc, printk(MYIOC_s_DEBUG_FMT
+   dfcprintk (ioc, printk(MYIOC_s_DEBUG_FMT
"%s.%d: %d:%d, executing recovery.\n", caller,
((MPT_SCSI_HOST *) shost->hostdata)->ioc->name,
((MPT_SCSI_HOST *) shost->hostdata)->ioc->sh->host_no,
@@ -605,7 +607,7 @@ mptfc_slave_alloc(struct scsi_device *sd
VirtDevice  *vdevice;
struct scsi_target  *starget;
struct fc_rport *rport;
-
+   MPT_ADAPTER *ioc;
 
starget = scsi_target(sdev);
rport = starget_to_rport(starget);
@@ -614,11 +616,12 @@ mptfc_slave_alloc(struct scsi_device *sd
return -ENXIO;
 
hd = (MPT_SCSI_HOST *)sdev->host->hostdata;
+   ioc = hd->ioc;
 
vdevice = kzalloc(sizeof(VirtDevice), GFP_KERNEL);
if (!vdevice) {
printk(MYIOC_s_ERR_FMT "slave_alloc kmalloc(%zd) FAILED!\n",
-   hd->ioc->name, sizeof(VirtDevice));
+   ioc->name, sizeof(VirtDevice));
return -ENOMEM;
}
 
@@ -627,7 +630,7 @@ mptfc_slave_alloc(struct scsi_device *sd
vtarget = starget->hostdata;
 
if (vtarget->num_luns == 0) {
-   vtarget->ioc_id = hd->ioc->id;
+   vtarget->ioc_id = ioc->id;
vtarget->tflags = MPT_TARGET_FLAGS_Q_YES;
}
 
@@ -637,7 +640,7 @@ mptfc_slave_alloc(struct scsi_device *sd
vtarget->num_luns++;
 
 
-   mptfc_dump_lun_info(hd->ioc, rport, sdev, vtarget);
+   mptfc_dump_lun_info(ioc, rport, sdev, vtarget);
 
return 0;
 }
diff -uarpN b/drivers/message/fusion/mptsas.c a/drivers/message/fusion/mptsas.c
--- b/drivers/message/fusion/mptsas.c   2007-09-14 16:41:07.0 -0600
+++ a/drivers/message/fusion/mptsas.c   2007-09-14 17:09:59.0 -0600
@@ -846,13 +846,14 @@ mptsas_target_alloc(struct scsi_target *
struct sas_rphy *rphy;
struct mptsas_portinfo  *p;
int  i;
+   MPT_ADAPTER *ioc = hd->ioc;
 
vtarget = kzalloc(sizeof(VirtTarget), GFP_KERNEL);
if (!vtarget)
return -ENOMEM;
 
vtarget->starget = starget;
-   vtarget->ioc_id = hd->ioc->id;
+   vtarget->ioc_id = ioc->id;
vtarget->tflags = MPT_TARGET_FLAGS_Q_YES;
id = starget->id;
channel = 0;
@@ -861,15 +862,15 @@ mptsas_target_alloc(struct scsi_target *
 * RAID volumes placed beyond the last expected port.
 */
if (starget->channel == MPTSAS_RAID_CHANNEL) {
-   for (i=0; i < hd->ioc->raid_data.pIocPg2->NumActiveVolumes; i++)
-   if (id == 
hd->ioc->raid_data.pIocPg2->RaidVolume[i].VolumeID)
-   channel = 
hd->ioc->raid_data.pIocPg2->RaidVolume[i].VolumeBus;
+   for (i=0; i < ioc->raid_data.pIocPg2->NumActiveVolumes; i++)
+   if (id == 
io

[PATCH 4/8] mpt fusion: rename vdev to vdevice

2007-09-14 Thread Eric Moore
common naming of vdevice through out driver

Signed-off-by: Eric Moore <[EMAIL PROTECTED]>

diff -uarpN b/drivers/message/fusion/mptctl.c a/drivers/message/fusion/mptctl.c
--- b/drivers/message/fusion/mptctl.c   2007-09-14 12:35:20.0 -0600
+++ a/drivers/message/fusion/mptctl.c   2007-09-14 16:42:19.0 -0600
@@ -1175,7 +1175,7 @@ mptctl_getiocinfo (unsigned long arg, un
int cim_rev;
u8  revision;
struct scsi_device  *sdev;
-   VirtDevice  *vdev;
+   VirtDevice  *vdevice;
 
/* Add of PCI INFO results in unaligned access for
 * IA64 and Sparc. Reset long to int. Return no PCI
@@ -1270,8 +1270,8 @@ mptctl_getiocinfo (unsigned long arg, un
karg->numDevices = 0;
if (ioc->sh) {
shost_for_each_device(sdev, ioc->sh) {
-   vdev = sdev->hostdata;
-   if (vdev->vtarget->tflags &
+   vdevice = sdev->hostdata;
+   if (vdevice->vtarget->tflags &
MPT_TARGET_FLAGS_RAID_COMPONENT)
continue;
karg->numDevices++;
@@ -1322,7 +1322,7 @@ mptctl_gettargetinfo (unsigned long arg)
struct mpt_ioctl_targetinfo __user *uarg = (void __user *) arg;
struct mpt_ioctl_targetinfo karg;
MPT_ADAPTER *ioc;
-   VirtDevice  *vdev;
+   VirtDevice  *vdevice;
char*pmem;
int *pdata;
int iocnum;
@@ -1391,13 +1391,13 @@ mptctl_gettargetinfo (unsigned long arg)
shost_for_each_device(sdev, ioc->sh) {
if (!maxWordsLeft)
continue;
-   vdev = sdev->hostdata;
-   if (vdev->vtarget->tflags &
+   vdevice = sdev->hostdata;
+   if (vdevice->vtarget->tflags &
MPT_TARGET_FLAGS_RAID_COMPONENT)
continue;
-   lun = (vdev->vtarget->raidVolume) ? 0x80 : vdev->lun;
-   *pdata = (((u8)lun << 16) + (vdev->vtarget->channel << 
8) +
-   (vdev->vtarget->id ));
+   lun = (vdevice->vtarget->raidVolume) ? 0x80 : 
vdevice->lun;
+   *pdata = (((u8)lun << 16) + (vdevice->vtarget->channel 
<< 8) +
+   (vdevice->vtarget->id ));
pdata++;
numDevices++;
--maxWordsLeft;
diff -uarpN b/drivers/message/fusion/mptfc.c a/drivers/message/fusion/mptfc.c
--- b/drivers/message/fusion/mptfc.c2007-09-14 14:08:51.0 -0600
+++ a/drivers/message/fusion/mptfc.c2007-09-14 16:39:53.0 -0600
@@ -213,7 +213,7 @@ mptfc_block_error_handler(struct scsi_cm
if (ready == DID_NO_CONNECT || !SCpnt->device->hostdata) {
dfcprintk (hd->ioc, printk(MYIOC_s_DEBUG_FMT
"%s.%d: %d:%d, failing recovery, "
-   "port state %d, vdev %p.\n", caller,
+   "port state %d, vdevice %p.\n", caller,
((MPT_SCSI_HOST *) shost->hostdata)->ioc->name,
((MPT_SCSI_HOST *) shost->hostdata)->ioc->sh->host_no,
SCpnt->device->id, SCpnt->device->lun, ready,
@@ -470,7 +470,7 @@ mptfc_register_dev(MPT_ADAPTER *ioc, int
/*
 * if already mapped, remap here.  If not mapped,
 * target_alloc will allocate vtarget and map,
-* slave_alloc will fill in vdev from vtarget.
+* slave_alloc will fill in vdevice from vtarget.
 */
if (ri->starget) {
vtarget = ri->starget->hostdata;
@@ -602,7 +602,7 @@ mptfc_slave_alloc(struct scsi_device *sd
 {
MPT_SCSI_HOST   *hd;
VirtTarget  *vtarget;
-   VirtDevice  *vdev;
+   VirtDevice  *vdevice;
struct scsi_target  *starget;
struct fc_rport *rport;
 
@@ -615,15 +615,15 @@ mptfc_slave_alloc(struct scsi_device *sd
 
hd = (MPT_SCSI_HOST *)sdev->host->hostdata;
 
-   vdev = kzalloc(sizeof(VirtDevice), GFP_KERNEL);
-   if (!vdev) {
+   vdevice = kzalloc(sizeof(VirtDevice), GFP_KERNEL);
+   if (!vdevice) {
printk(MYIOC_s_ERR_FMT "slave_alloc kmalloc(%zd) FAILED!\n",
hd->ioc->name, sizeof(VirtDevice));
return -ENOMEM;
}
 
 
-   sdev->hostdata = vdev;
+   sdev->hostdata = vdevice;
vtarget = starget->hostdata;
 
if (vtarget->num_luns == 0) {
@@ -631,8 +631,8 @@ mptfc_sla

[PATCH 3/8] mpt fusion: adding/removing white space

2007-09-14 Thread Eric Moore
cleaning up some white space that was introduce in a recent "cb_idx int to u8" 
patch.

Signed-off-by: Eric Moore <[EMAIL PROTECTED]>

diff -uarpN b/drivers/message/fusion/mptbase.c 
a/drivers/message/fusion/mptbase.c
--- b/drivers/message/fusion/mptbase.c  2007-09-14 17:23:24.0 -0600
+++ a/drivers/message/fusion/mptbase.c  2007-09-14 17:26:18.0 -0600
@@ -305,7 +305,7 @@ mpt_turbo_reply(MPT_ADAPTER *ioc, u32 pa
 
/*  Check for (valid) IO callback!  */
if (!cb_idx || cb_idx >= MPT_MAX_PROTOCOL_DRIVERS ||
-   MptCallbacks[cb_idx] == NULL) {
+   MptCallbacks[cb_idx] == NULL) {
printk(MYIOC_s_WARN_FMT "%s: Invalid cb_idx (%d)!\n",
__FUNCTION__, ioc->name, cb_idx);
goto out;
@@ -369,7 +369,7 @@ mpt_reply(MPT_ADAPTER *ioc, u32 pa)
 
/*  Check for (valid) IO callback!  */
if (!cb_idx || cb_idx >= MPT_MAX_PROTOCOL_DRIVERS ||
-   MptCallbacks[cb_idx] == NULL) {
+   MptCallbacks[cb_idx] == NULL) {
printk(MYIOC_s_WARN_FMT "%s: Invalid cb_idx (%d)!\n",
__FUNCTION__, ioc->name, cb_idx);
freeme = 0;
@@ -621,7 +621,7 @@ mpt_register(MPT_CALLBACK cbfunc, MPT_DR
 void
 mpt_deregister(u8 cb_idx)
 {
-   if (cb_idx  && (cb_idx < MPT_MAX_PROTOCOL_DRIVERS)) {
+   if (cb_idx && (cb_idx < MPT_MAX_PROTOCOL_DRIVERS)) {
MptCallbacks[cb_idx] = NULL;
MptDriverClass[cb_idx] = MPTUNKNOWN_DRIVER;
MptEvHandlers[cb_idx] = NULL;
@@ -645,7 +645,7 @@ mpt_deregister(u8 cb_idx)
 int
 mpt_event_register(u8 cb_idx, MPT_EVHANDLER ev_cbfunc)
 {
-   if (!cb_idx  || cb_idx >= MPT_MAX_PROTOCOL_DRIVERS)
+   if (!cb_idx || cb_idx >= MPT_MAX_PROTOCOL_DRIVERS)
return -1;
 
MptEvHandlers[cb_idx] = ev_cbfunc;
@@ -665,7 +665,7 @@ mpt_event_register(u8 cb_idx, MPT_EVHAND
 void
 mpt_event_deregister(u8 cb_idx)
 {
-   if (!cb_idx  || cb_idx >= MPT_MAX_PROTOCOL_DRIVERS)
+   if (!cb_idx || cb_idx >= MPT_MAX_PROTOCOL_DRIVERS)
return;
 
MptEvHandlers[cb_idx] = NULL;
@@ -722,7 +722,7 @@ mpt_device_driver_register(struct mpt_pc
MPT_ADAPTER *ioc;
const struct pci_device_id *id;
 
-   if (!cb_idx  || cb_idx >= MPT_MAX_PROTOCOL_DRIVERS)
+   if (!cb_idx || cb_idx >= MPT_MAX_PROTOCOL_DRIVERS)
return -EINVAL;
 
MptDeviceDriverHandlers[cb_idx] = dd_cbfunc;
@@ -749,7 +749,7 @@ mpt_device_driver_deregister(u8 cb_idx)
struct mpt_pci_driver *dd_cbfunc;
MPT_ADAPTER *ioc;
 
-   if (!cb_idx  || cb_idx >= MPT_MAX_PROTOCOL_DRIVERS)
+   if (!cb_idx || cb_idx >= MPT_MAX_PROTOCOL_DRIVERS)
return;
 
dd_cbfunc = MptDeviceDriverHandlers[cb_idx];
@@ -1681,7 +1681,7 @@ mpt_attach(struct pci_dev *pdev, const s
}
 
/* call per device driver probe entry point */
-   for(cb_idx=0; cb_idxprobe) {
MptDeviceDriverHandlers[cb_idx]->probe(pdev,id);
@@ -1731,7 +1731,7 @@ mpt_detach(struct pci_dev *pdev)
remove_proc_entry(pname, NULL);
 
/* call per device driver remove entry point */
-   for(cb_idx=0; cb_idxremove) {
MptDeviceDriverHandlers[cb_idx]->remove(pdev);
@@ -5933,7 +5933,7 @@ procmpt_version_read(char *buf, char **s
len += sprintf(buf+len, "  Fusion MPT base driver\n");
 
scsi = fc = sas = lan = ctl = targ = dmp = 0;
-   for (cb_idx=MPT_MAX_PROTOCOL_DRIVERS-1; cb_idx; cb_idx--) {
+   for (cb_idx = MPT_MAX_PROTOCOL_DRIVERS-1; cb_idx; cb_idx--) {
drvname = NULL;
if (MptCallbacks[cb_idx]) {
switch (MptDriverClass[cb_idx]) {
@@ -6676,7 +6676,7 @@ ProcessEventNotification(MPT_ADAPTER *io
/*
 *  Call each currently registered protocol event handler.
 */
-   for (cb_idx=MPT_MAX_PROTOCOL_DRIVERS-1; cb_idx; cb_idx--) {
+   for (cb_idx = MPT_MAX_PROTOCOL_DRIVERS-1; cb_idx; cb_idx--) {
if (MptEvHandlers[cb_idx]) {
devtverboseprintk(ioc, printk(MYIOC_s_DEBUG_FMT 
"Routing Event to event handler #%d\n",
ioc->name, cb_idx));
-
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/8] mpt fusion: mm merges

2007-09-14 Thread Eric Moore
These fixes from -mm tree need to be merged in James git tree.  Here is a 
single patch containing all four patchs changes.  They address some memory 
leaks, menuobject support, kill redundant memset, and using kzalloc.

List of patchs, and pointers to archives:

[patch 08/30] Use menuconfig objects: Fusion
http://marc.info/?l=linux-scsi&m=118678275800902&w=2
[patch 26/30] drivers/message/fusion/mptctl.c: mostly kmalloc + memset 
conversion to kzalloc
http://marc.info/?l=linux-scsi&m=118678346112881&w=2
[patch 27/30] mpt-fusion: fix two potential mem leaks
http://marc.info/?l=linux-scsi&m=118678345904954&w=2
[patch 30/30] message/fusion: remove redundant memset
http://marc.info/?l=linux-scsi&m=118678345816541&w=2

Signed-off-by: Eric Moore <[EMAIL PROTECTED]>

diff --git a/drivers/message/fusion/Kconfig b/drivers/message/fusion/Kconfig
index 3c44a2f..9b87c2f 100644
--- a/drivers/message/fusion/Kconfig
+++ b/drivers/message/fusion/Kconfig
@@ -1,15 +1,19 @@
 
-menu "Fusion MPT device support"
+menuconfig FUSION
+   bool "Fusion MPT device support"
depends on PCI
+   ---help---
+   Say Y here to get to see options for Fusion Message
+   Passing Technology (MPT) drivers.
+   This option alone does not add any kernel code.
+
+   If you say N, all options in this submenu will be skipped and disabled.
 
-config FUSION
-   bool
-   default n
+if FUSION
 
 config FUSION_SPI
tristate "Fusion MPT ScsiHost drivers for SPI"
depends on PCI && SCSI
-   select FUSION
select SCSI_SPI_ATTRS
---help---
  SCSI HOST support for a parallel SCSI host adapters.
@@ -25,7 +29,6 @@ config FUSION_SPI
 config FUSION_FC
tristate "Fusion MPT ScsiHost drivers for FC"
depends on PCI && SCSI
-   select FUSION
select SCSI_FC_ATTRS
---help---
  SCSI HOST support for a Fiber Channel host adapters.
@@ -43,7 +46,6 @@ config FUSION_FC
 config FUSION_SAS
tristate "Fusion MPT ScsiHost drivers for SAS"
depends on PCI && SCSI
-   select FUSION
select SCSI_SAS_ATTRS
---help---
  SCSI HOST support for a SAS host adapters.
@@ -57,7 +59,6 @@ config FUSION_SAS
 
 config FUSION_MAX_SGE
int "Maximum number of scatter gather entries (16 - 128)"
-   depends on FUSION
default "128"
range 16 128
help
@@ -117,4 +118,4 @@ config FUSION_LOGGING
  There are various debug levels that an be found in the source:
  file:drivers/message/fusion/mptdebug.h
 
-endmenu
+endif # FUSION
diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index 22cb0f8..635defd 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -1458,18 +1458,18 @@ mpt_attach(struct pci_dev *pdev, const s
struct proc_dir_entry *dent, *ent;
 #endif
 
+   if (mpt_debug_level)
+   printk(KERN_INFO MYNAM ": mpt_debug_level=%xh\n", 
mpt_debug_level);
+
+   if (pci_enable_device(pdev))
+   return r;
+
ioc = kzalloc(sizeof(MPT_ADAPTER), GFP_ATOMIC);
if (ioc == NULL) {
printk(KERN_ERR MYNAM ": ERROR - Insufficient memory to add 
adapter!\n");
return -ENOMEM;
}
-
ioc->debug_level = mpt_debug_level;
-   if (mpt_debug_level)
-   printk(KERN_INFO MYNAM ": mpt_debug_level=%xh\n", 
mpt_debug_level);
-
-   if (pci_enable_device(pdev))
-   return r;
 
dinitprintk(ioc, printk(KERN_WARNING MYNAM ": mpt_adapter_install\n"));
 
@@ -1478,6 +1478,7 @@ mpt_attach(struct pci_dev *pdev, const s
": 64 BIT PCI BUS DMA ADDRESSING SUPPORTED\n"));
} else if (pci_set_dma_mask(pdev, DMA_32BIT_MASK)) {
printk(KERN_WARNING MYNAM ": 32 BIT PCI BUS DMA ADDRESSING NOT 
SUPPORTED\n");
+   kfree(ioc);
return r;
}
 
diff --git a/drivers/message/fusion/mptctl.c b/drivers/message/fusion/mptctl.c
index b9618f4..12dfa2e 100644
--- a/drivers/message/fusion/mptctl.c
+++ b/drivers/message/fusion/mptctl.c
@@ -977,10 +977,9 @@ kbuf_alloc_2_sgl(int bytes, u32 sgdir, i
 * structures for the SG elements.
 */
i = MAX_SGL_BYTES / 8;
-   buflist = kmalloc(i, GFP_USER);
-   if (buflist == NULL)
+   buflist = kzalloc(i, GFP_USER);
+   if (!buflist)
return NULL;
-   memset(buflist, 0, i);
buflist_ent = 0;
 
/* Allocate a single block of memory to store the sg elements and
@@ -1379,13 +1378,12 @@ mptctl_gettargetinfo (unsigned long arg)
 *  15- 8: Bus Number
 *   7- 0: Target ID
 */
-   pmem = kmalloc(numBytes, GFP_KERNEL);
-   if (pmem == NULL) {
+   pmem = kzalloc(numBytes, GFP_KERNEL);
+   if (!pmem) {
printk(KERN_ERR "%s::mptctl_gettargetinfo() @%d - no memory 
available!\n",
  

[PATCH 0/8] mpt fusion

2007-09-14 Thread Eric Moore
These set of patchs are for scsi-misc git, hence post 2.6.23 kernels.  These 
basically cleaning up a large part of the code.

Contents of this series of patchs:

1) mm merges
2) standardize printks and debug info
3) adding/removing white space
4) rename vdev to vdevice
5) removing references to hd->ioc
6) removing Dell copyright
7) Kconfig cleanup
8) bump version to 3.04.06
-
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 update] SCSI: update Kconfig help text to indicate SCSI core's widespread usage

2007-09-14 Thread FUJITA Tomonori
On Fri, 14 Sep 2007 23:14:21 +0200 (CEST)
Stefan Richter <[EMAIL PROTECTED]> wrote:

> Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
> ---
> 
> And one more update:
> There is SAS too, and I forgot 'is' in "on a disk which __ accessed via".
> 
>  drivers/scsi/Kconfig |   67 ++-
>  1 file changed, 35 insertions(+), 32 deletions(-)
> 
> Index: linux-2.6.23-rc6/drivers/scsi/Kconfig
> ===
> --- linux-2.6.23-rc6.orig/drivers/scsi/Kconfig
> +++ linux-2.6.23-rc6/drivers/scsi/Kconfig
> @@ -12,23 +12,31 @@ config SCSI
>   depends on BLOCK
>   select SCSI_DMA if HAS_DMA
>   ---help---
> -   If you want to use a SCSI hard disk, SCSI tape drive, SCSI CD-ROM or
> -   any other SCSI device under Linux, say Y and make sure that you know
> -   the name of your SCSI host adapter (the card inside your computer
> -   that "speaks" the SCSI protocol, also called SCSI controller),
> -   because you will be asked for it.
> -
> -   You also need to say Y here if you have a device which speaks
> -   the SCSI protocol.  Examples of this include the parallel port
> -   version of the IOMEGA ZIP drive, USB storage devices, Fibre
> -   Channel, FireWire storage and the IDE-SCSI emulation driver.
> +   This option enables core support for SCSI protocols.
> +   You need it
> +   - for classic parallel SCSI hardware,
> +   - for newer SCSI transports such as Fibre Channel, FireWire storage,
> + SAS, or iSCSI,

There is SRP too.
-
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


command failing at iSCSI disconnect

2007-09-14 Thread Dave Jiang
I'm using the latest linus git tree. This is in fileio mode with
IOMode=wb. It seems that if I do I/O and then immediately disconnect
then the cache sync commands fail. Is this expected behavior or should
the connection wait till all existing commands has been flushed before
logout? Thanks!

[EMAIL PROTECTED]:~/iscsi2# iscsiadm -m node -T
iqn.2007.com.mvista:disk1 -p 192.168.1.239:3260 --logout
Logout session [sd 1:0:0:0: [sdb] Synchronizing SCSI cache
sid: 1, target: iqn.2007.com.mvista:disk1, portal: 192.168.1.239,3260]
iscsi: cmd 0x35 is not queued (6)
iscsi: cmd 0x35 is not queued (6)
iscsi: cmd 0x35 is not queued (6)
sd 1:0:0:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00
-
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 9018] New: Kernel bug in aic94xx driver shipped with kernel 2.6.21.7

2007-09-14 Thread James Bottomley
On Fri, 2007-09-14 at 13:56 -0700, Andrew Morton wrote:
> On Fri, 14 Sep 2007 07:11:54 -0700 (PDT)
> [EMAIL PROTECTED] wrote:
> 
> > http://bugzilla.kernel.org/show_bug.cgi?id=9018
> > 
> >Summary: Kernel bug in aic94xx driver shipped with kernel
> > 2.6.21.7
> >Product: Drivers
> >Version: 2.5
> >  KernelVersion: 2.6.21.7
> >   Platform: All
> > OS/Version: Linux
> >   Tree: Mainline
> > Status: NEW
> >   Severity: normal
> >   Priority: P1
> >  Component: Other
> > AssignedTo: [EMAIL PROTECTED]
> > ReportedBy: [EMAIL PROTECTED]
> > 
> > 
> > While rebuilding a MD raid5, every time I try to rebuild:
> > 
> > -- START DUMP --
> > RAID5 conf printout:
> >  --- rd:3 wd:2
> >  disk 0, o:1, dev:sdb1
> >  disk 1, o:1, dev:sdc1
> >  disk 2, o:1, dev:sdd1
> > md: recovery of RAID array md0
> > md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
> > md: using maximum available idle IO bandwidth (but not more than 20 
> > KB/sec)
> > for recovery.
> > md: using 128k window, over a total of 71681920 blocks.
> > [ cut here ]
> > kernel BUG at drivers/scsi/aic94xx/aic94xx_hwi.h:354!
> 
> whee!  That's BUG_ON(!list_empty(&ascb->list));

Yes; it means the task was still in use when we tried to free it.  I
surmise that this is the tascb not the ascb in asd_abort_task(). What
this seems to indicate is some sort of race between the abort completing
the task and the owning entity taking it off the sequencer list.

I don't understand this piece of the driver enough yet to fix a more
definite cause.

> yet anoher scsi driver with no entry in MAINTAINERS.  Darrick, maybe?

Gilbert Wu should be taking over eventually, but for now it's a bit
unmaintained.

James


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH update] SCSI: update Kconfig help text to indicate SCSI core's widespread usage

2007-09-14 Thread Stefan Richter
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---

And one more update:
There is SAS too, and I forgot 'is' in "on a disk which __ accessed via".

 drivers/scsi/Kconfig |   67 ++-
 1 file changed, 35 insertions(+), 32 deletions(-)

Index: linux-2.6.23-rc6/drivers/scsi/Kconfig
===
--- linux-2.6.23-rc6.orig/drivers/scsi/Kconfig
+++ linux-2.6.23-rc6/drivers/scsi/Kconfig
@@ -12,23 +12,31 @@ config SCSI
depends on BLOCK
select SCSI_DMA if HAS_DMA
---help---
- If you want to use a SCSI hard disk, SCSI tape drive, SCSI CD-ROM or
- any other SCSI device under Linux, say Y and make sure that you know
- the name of your SCSI host adapter (the card inside your computer
- that "speaks" the SCSI protocol, also called SCSI controller),
- because you will be asked for it.
-
- You also need to say Y here if you have a device which speaks
- the SCSI protocol.  Examples of this include the parallel port
- version of the IOMEGA ZIP drive, USB storage devices, Fibre
- Channel, FireWire storage and the IDE-SCSI emulation driver.
+ This option enables core support for SCSI protocols.
+ You need it
+ - for classic parallel SCSI hardware,
+ - for newer SCSI transports such as Fibre Channel, FireWire storage,
+   SAS, or iSCSI,
+ - for non-SCSI hardware which speaks SCSI protocols, such as USB
+   storage devices or the parallel port version of Iomega Zip drive,
+ - for non-SCSI hardware whose drivers translate from and to SCSI
+   protocols, most notably all Serial ATA drivers, and Parallel ATA
+   via the ATA configuration option.
 
  To compile this driver as a module, choose M here and read
  .
  The module will be called scsi_mod.
 
  However, do not compile this as a module if your root file system
- (the one containing the directory /) is located on a SCSI device.
+ (the one containing the directory /) is located on a SCSI device
+ or on a device whose driver represents it as SCSI device, as
+ indicated above.  Choose Y in this case, or set up an initrd.
+
+ Subsequent options in this menu enable specific SCSI command set
+ support for harddisks, CD/DVD-ROM/R/W, tapes etc..  This menu also
+ presents options for specific SCSI controllers, while options for
+ some other SCSI transports and all non-SCSI controllers are located
+ in other menus (SATA, USB, FireWire etc.).
 
 config SCSI_DMA
bool
@@ -57,32 +65,27 @@ config SCSI_PROC_FS
 
  If unsure say Y.
 
-comment "SCSI support type (disk, tape, CD-ROM)"
+comment "SCSI command set drivers (disk, tape, CD-ROM)"
depends on SCSI
 
 config BLK_DEV_SD
-   tristate "SCSI disk support"
+   tristate "Harddisks and other Direct access devices"
depends on SCSI
---help---
- If you want to use SCSI hard disks, Fibre Channel disks,
- Serial ATA (SATA) or Parallel ATA (PATA) hard disks,
- USB storage or the SCSI or parallel port version of
- the IOMEGA ZIP drive, say Y and read the SCSI-HOWTO,
- the Disk-HOWTO and the Multi-Disk-HOWTO, available from
- . This is NOT for SCSI
- CD-ROMs.
+ Say Y if you want to use harddisks and similar block-oriented devices
+ via SCSI or via drivers which use SCSI command sets (e.g. the Serial
+ and Parallel ATA kernel subsystem, USB, and more).
 
  To compile this driver as a module, choose M here and read
  .
  The module will be called sd_mod.
 
- Do not compile this driver as a module if your root file system
- (the one containing the directory /) is located on a SCSI disk.
- In this case, do not compile the driver for your SCSI host adapter
- (below) as a module either.
+ If your root file system (the one containing the directory /) is
+ located on a disk which is accessed via this driver, choose Y rather
+ than M or set up a suitable initrd.
 
 config CHR_DEV_ST
-   tristate "SCSI tape support"
+   tristate "Tape drives"
depends on SCSI
---help---
  If you want to use a SCSI tape drive under Linux, say Y and read the
@@ -95,7 +98,7 @@ config CHR_DEV_ST
  . The module will be called st.
 
 config CHR_DEV_OSST
-   tristate "SCSI OnStream SC-x0 tape support"
+   tristate "SCSI OnStream SC-x0 tape drives"
depends on SCSI
---help---
  The OnStream SC-x0 SCSI tape drives cannot be driven by the
@@ -117,13 +120,13 @@ config CHR_DEV_OSST
  . The module will be called osst.
 
 config BLK_DEV_SR
-   tristate "SCSI CDROM support"
+   tristate "CD-ROMs, D

Re: [Bugme-new] [Bug 9018] New: Kernel bug in aic94xx driver shipped with kernel 2.6.21.7

2007-09-14 Thread Jeff Garzik

Andrew Morton wrote:

On Fri, 14 Sep 2007 07:11:54 -0700 (PDT)
[EMAIL PROTECTED] wrote:


http://bugzilla.kernel.org/show_bug.cgi?id=9018

   Summary: Kernel bug in aic94xx driver shipped with kernel
2.6.21.7
   Product: Drivers
   Version: 2.5
 KernelVersion: 2.6.21.7
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Other
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


While rebuilding a MD raid5, every time I try to rebuild:

-- START DUMP --
RAID5 conf printout:
 --- rd:3 wd:2
 disk 0, o:1, dev:sdb1
 disk 1, o:1, dev:sdc1
 disk 2, o:1, dev:sdd1
md: recovery of RAID array md0
md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
md: using maximum available idle IO bandwidth (but not more than 20 KB/sec)
for recovery.
md: using 128k window, over a total of 71681920 blocks.
[ cut here ]
kernel BUG at drivers/scsi/aic94xx/aic94xx_hwi.h:354!


whee!  That's BUG_ON(!list_empty(&ascb->list));

yet anoher scsi driver with no entry in MAINTAINERS.  Darrick, maybe?


Quite honestly, that's the reality of the situation for (IMO) the 
majority of SCSI drivers.  They just don't really have maintainers at 
all, so it winds up falling onto the subsystem maintainer(s) by default.


[EMAIL PROTECTED] just posted a patch to the driver, so he should 
probably be kept in the loop.


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: update Kconfig help text to indicate SCSI core's widespread usage

2007-09-14 Thread Lennart Sorensen
On Fri, Sep 14, 2007 at 11:06:44PM +0200, Stefan Richter wrote:
> On 14 Sep, Lennart Sorensen wrote:
> > On Fri, Sep 14, 2007 at 10:14:16PM +0200, Stefan Richter wrote:
> >> -If you want to use a SCSI or FireWire CD-ROM under Linux,
> >> +If you want to use a SCSI, SATA, USB or FireWire CD-ROM or DVD-ROM,
> >>  say Y and read the SCSI-HOWTO and the CDROM-HOWTO at
> >>  . Also make sure to say
> >>  Y or M to "ISO 9660 CD-ROM file system support" later.
> > 
> > How about that one for libata driven PATA CDROM drives?  Could replace
> > SATA with libata, or something similar.
> 
> 
> From: Stefan Richter <[EMAIL PROTECTED]>
> Subject: SCSI: update Kconfig help text to indicate SCSI core's widespread 
> usage
> 
> Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
> ---
>  drivers/scsi/Kconfig |   67 ++-
>  1 file changed, 35 insertions(+), 32 deletions(-)
> 
> Index: linux-2.6.23-rc6/drivers/scsi/Kconfig
> ===
> --- linux-2.6.23-rc6.orig/drivers/scsi/Kconfig
> +++ linux-2.6.23-rc6/drivers/scsi/Kconfig
> @@ -12,23 +12,31 @@ config SCSI
>   depends on BLOCK
>   select SCSI_DMA if HAS_DMA
>   ---help---
> -   If you want to use a SCSI hard disk, SCSI tape drive, SCSI CD-ROM or
> -   any other SCSI device under Linux, say Y and make sure that you know
> -   the name of your SCSI host adapter (the card inside your computer
> -   that "speaks" the SCSI protocol, also called SCSI controller),
> -   because you will be asked for it.
> -
> -   You also need to say Y here if you have a device which speaks
> -   the SCSI protocol.  Examples of this include the parallel port
> -   version of the IOMEGA ZIP drive, USB storage devices, Fibre
> -   Channel, FireWire storage and the IDE-SCSI emulation driver.
> +   This option enables core support for SCSI protocols.
> +   You need it
> +   - for classic parallel SCSI hardware,
> +   - for newer SCSI transports such as Fibre Channel, FireWire storage,
> + or iSCSI,
> +   - for non-SCSI hardware which speaks SCSI protocols, such as USB
> + storage devices or the parallel port version of Iomega Zip drive,
> +   - for non-SCSI hardware whose drivers translate from and to SCSI
> + protocols, most notably all Serial ATA drivers, and Parallel ATA
> + via the ATA configuration option.
>  
> To compile this driver as a module, choose M here and read
> .
> The module will be called scsi_mod.
>  
> However, do not compile this as a module if your root file system
> -   (the one containing the directory /) is located on a SCSI device.
> +   (the one containing the directory /) is located on a SCSI device
> +   or on a device whose driver represents it as SCSI device, as
> +   indicated above.  Choose Y in this case, or set up an initrd.
> +
> +   Subsequent options in this menu enable specific SCSI command set
> +   support for harddisks, CD/DVD-ROM/R/W, tapes etc..  This menu also
> +   presents options for specific SCSI controllers, while options for
> +   some other SCSI transports and all non-SCSI controllers are located
> +   in other menus (SATA, USB, FireWire etc.).
>  
>  config SCSI_DMA
>   bool
> @@ -57,32 +65,27 @@ config SCSI_PROC_FS
>  
> If unsure say Y.
>  
> -comment "SCSI support type (disk, tape, CD-ROM)"
> +comment "SCSI command set drivers (disk, tape, CD-ROM)"
>   depends on SCSI
>  
>  config BLK_DEV_SD
> - tristate "SCSI disk support"
> + tristate "Harddisks and other Direct access devices"
>   depends on SCSI
>   ---help---
> -   If you want to use SCSI hard disks, Fibre Channel disks,
> -   Serial ATA (SATA) or Parallel ATA (PATA) hard disks,
> -   USB storage or the SCSI or parallel port version of
> -   the IOMEGA ZIP drive, say Y and read the SCSI-HOWTO,
> -   the Disk-HOWTO and the Multi-Disk-HOWTO, available from
> -   . This is NOT for SCSI
> -   CD-ROMs.
> +   Say Y if you want to use harddisks and similar block-oriented devices
> +   via SCSI or via drivers which use SCSI command sets (e.g. the Serial
> +   and Parallel ATA kernel subsystem, USB, and more).
>  
> To compile this driver as a module, choose M here and read
> .
> The module will be called sd_mod.
>  
> -   Do not compile this driver as a module if your root file system
> -   (the one containing the directory /) is located on a SCSI disk.
> -   In this case, do not compile the driver for your SCSI host adapter
> -   (below) as a module either.
> +   If your root file system (the one containing the directory /) is
> +   located on a disk which accessed via this driver, choose Y instead of
> +   M or set up 

Re: [PATCH] SCSI: update Kconfig help text to indicate SCSI core's widespread usage

2007-09-14 Thread Stefan Richter
On 14 Sep, Lennart Sorensen wrote:
> On Fri, Sep 14, 2007 at 10:14:16PM +0200, Stefan Richter wrote:
>> -  If you want to use a SCSI or FireWire CD-ROM under Linux,
>> +  If you want to use a SCSI, SATA, USB or FireWire CD-ROM or DVD-ROM,
>>say Y and read the SCSI-HOWTO and the CDROM-HOWTO at
>>. Also make sure to say
>>Y or M to "ISO 9660 CD-ROM file system support" later.
> 
> How about that one for libata driven PATA CDROM drives?  Could replace
> SATA with libata, or something similar.


From: Stefan Richter <[EMAIL PROTECTED]>
Subject: SCSI: update Kconfig help text to indicate SCSI core's widespread usage

Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
 drivers/scsi/Kconfig |   67 ++-
 1 file changed, 35 insertions(+), 32 deletions(-)

Index: linux-2.6.23-rc6/drivers/scsi/Kconfig
===
--- linux-2.6.23-rc6.orig/drivers/scsi/Kconfig
+++ linux-2.6.23-rc6/drivers/scsi/Kconfig
@@ -12,23 +12,31 @@ config SCSI
depends on BLOCK
select SCSI_DMA if HAS_DMA
---help---
- If you want to use a SCSI hard disk, SCSI tape drive, SCSI CD-ROM or
- any other SCSI device under Linux, say Y and make sure that you know
- the name of your SCSI host adapter (the card inside your computer
- that "speaks" the SCSI protocol, also called SCSI controller),
- because you will be asked for it.
-
- You also need to say Y here if you have a device which speaks
- the SCSI protocol.  Examples of this include the parallel port
- version of the IOMEGA ZIP drive, USB storage devices, Fibre
- Channel, FireWire storage and the IDE-SCSI emulation driver.
+ This option enables core support for SCSI protocols.
+ You need it
+ - for classic parallel SCSI hardware,
+ - for newer SCSI transports such as Fibre Channel, FireWire storage,
+   or iSCSI,
+ - for non-SCSI hardware which speaks SCSI protocols, such as USB
+   storage devices or the parallel port version of Iomega Zip drive,
+ - for non-SCSI hardware whose drivers translate from and to SCSI
+   protocols, most notably all Serial ATA drivers, and Parallel ATA
+   via the ATA configuration option.
 
  To compile this driver as a module, choose M here and read
  .
  The module will be called scsi_mod.
 
  However, do not compile this as a module if your root file system
- (the one containing the directory /) is located on a SCSI device.
+ (the one containing the directory /) is located on a SCSI device
+ or on a device whose driver represents it as SCSI device, as
+ indicated above.  Choose Y in this case, or set up an initrd.
+
+ Subsequent options in this menu enable specific SCSI command set
+ support for harddisks, CD/DVD-ROM/R/W, tapes etc..  This menu also
+ presents options for specific SCSI controllers, while options for
+ some other SCSI transports and all non-SCSI controllers are located
+ in other menus (SATA, USB, FireWire etc.).
 
 config SCSI_DMA
bool
@@ -57,32 +65,27 @@ config SCSI_PROC_FS
 
  If unsure say Y.
 
-comment "SCSI support type (disk, tape, CD-ROM)"
+comment "SCSI command set drivers (disk, tape, CD-ROM)"
depends on SCSI
 
 config BLK_DEV_SD
-   tristate "SCSI disk support"
+   tristate "Harddisks and other Direct access devices"
depends on SCSI
---help---
- If you want to use SCSI hard disks, Fibre Channel disks,
- Serial ATA (SATA) or Parallel ATA (PATA) hard disks,
- USB storage or the SCSI or parallel port version of
- the IOMEGA ZIP drive, say Y and read the SCSI-HOWTO,
- the Disk-HOWTO and the Multi-Disk-HOWTO, available from
- . This is NOT for SCSI
- CD-ROMs.
+ Say Y if you want to use harddisks and similar block-oriented devices
+ via SCSI or via drivers which use SCSI command sets (e.g. the Serial
+ and Parallel ATA kernel subsystem, USB, and more).
 
  To compile this driver as a module, choose M here and read
  .
  The module will be called sd_mod.
 
- Do not compile this driver as a module if your root file system
- (the one containing the directory /) is located on a SCSI disk.
- In this case, do not compile the driver for your SCSI host adapter
- (below) as a module either.
+ If your root file system (the one containing the directory /) is
+ located on a disk which accessed via this driver, choose Y instead of
+ M or set up a suitable initrd.
 
 config CHR_DEV_ST
-   tristate "SCSI tape support"
+   tristate "Tape drives"
depends on SCSI
 

Re: [Bugme-new] [Bug 9018] New: Kernel bug in aic94xx driver shipped with kernel 2.6.21.7

2007-09-14 Thread Andrew Morton
On Fri, 14 Sep 2007 07:11:54 -0700 (PDT)
[EMAIL PROTECTED] wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=9018
> 
>Summary: Kernel bug in aic94xx driver shipped with kernel
> 2.6.21.7
>Product: Drivers
>Version: 2.5
>  KernelVersion: 2.6.21.7
>   Platform: All
> OS/Version: Linux
>   Tree: Mainline
> Status: NEW
>   Severity: normal
>   Priority: P1
>  Component: Other
> AssignedTo: [EMAIL PROTECTED]
> ReportedBy: [EMAIL PROTECTED]
> 
> 
> While rebuilding a MD raid5, every time I try to rebuild:
> 
> -- START DUMP --
> RAID5 conf printout:
>  --- rd:3 wd:2
>  disk 0, o:1, dev:sdb1
>  disk 1, o:1, dev:sdc1
>  disk 2, o:1, dev:sdd1
> md: recovery of RAID array md0
> md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
> md: using maximum available idle IO bandwidth (but not more than 20 
> KB/sec)
> for recovery.
> md: using 128k window, over a total of 71681920 blocks.
> [ cut here ]
> kernel BUG at drivers/scsi/aic94xx/aic94xx_hwi.h:354!

whee!  That's BUG_ON(!list_empty(&ascb->list));

yet anoher scsi driver with no entry in MAINTAINERS.  Darrick, maybe?

> invalid opcode:  [1] SMP
> CPU 1
> Modules linked in: aic94xx
> Pid: 1182, comm: scsi_eh_2 Not tainted 2.6.21.7 #2
> RIP: 0010:[]  []
> :aic94xx:asd_abort_task+0x3c3/0x4d6
> RSP: 0018:81022e4c5d80  EFLAGS: 00010287
> RAX:  RBX: 810228226380 RCX: 0001
> RDX: 810228226410 RSI: 0282 RDI: 8102280d1098
> RBP: 81022fb08000 R08:  R09: 0001
> R10: 0001 R11: 81022e3b4480 R12: 810228224c80
> R13:  R14: 8102280d1098 R15: 810228226380
> FS:  () GS:81022fc3a940() knlGS:
> CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
> CR2: 005b2b50 CR3: 00201000 CR4: 06e0
> Process scsi_eh_2 (pid: 1182, threadinfo 81022e4c4000, task
> 81022f470440)
> Stack:  81022f470440 018de129b192 2fe8c100 81022fb08108
>   8102280d1080 8102280d1098 81022e4c5eb0
>  810228262a80 803c4f1b  81022e4c5e20
> Call Trace:
>  [] sas_scsi_recover_host+0x1eb/0x690
>  [] scsi_error_handler+0xa5/0x300
>  [] scsi_error_handler+0x0/0x300
>  [] keventd_create_kthread+0x0/0x65
>  [] kthread+0xcb/0xf5
>  [] child_rip+0xa/0x12
>  [] keventd_create_kthread+0x0/0x65
>  [] kthread+0x0/0xf5
>  [] child_rip+0x0/0x12
> 
> 
> Code: 0f 0b eb fe 48 8d bd f0 41 00 00 e8 c6 91 25 f8 48 89 c6 8b
> RIP  [] :aic94xx:asd_abort_task+0x3c3/0x4d6
>  RSP 
> -- END DUMP --
> 
> 
> -- 
> Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
> --- 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: [RFC PATCH] SCSI: split Kconfig menu into two

2007-09-14 Thread Stefan Richter
I wrote:
> Applies after patch "SCSI: update Kconfig help text to indicate SCSI
> core's widespread usage",

Actually the addition "This menu also presents options for specific SCSI
controllers..." from that patch is then no longer true.

> These two patches could very well be collapsed into one.

(I'll gladly do that, or only send an update of the 'split Kconfig menu'
patch with that sentence backed out, if desired.)
-- 
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] SCSI: update Kconfig help text to indicate SCSI core's widespread usage

2007-09-14 Thread Lennart Sorensen
On Fri, Sep 14, 2007 at 10:14:16PM +0200, Stefan Richter wrote:
> -   If you want to use a SCSI or FireWire CD-ROM under Linux,
> +   If you want to use a SCSI, SATA, USB or FireWire CD-ROM or DVD-ROM,
> say Y and read the SCSI-HOWTO and the CDROM-HOWTO at
> . Also make sure to say
> Y or M to "ISO 9660 CD-ROM file system support" later.

How about that one for libata driven PATA CDROM drives?  Could replace
SATA with libata, or something similar.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: 2.6.23-rc4-mm1

2007-09-14 Thread Andrew Morton
On Fri, 14 Sep 2007 15:01:03 +0200 "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:

> On 9/14/07, Andy Whitcroft <[EMAIL PROTECTED]> wrote:
> > On Tue, Sep 11, 2007 at 04:31:12AM +0900, FUJITA Tomonori wrote:
> > [...]
> > >
> > > Even if we revert the qla1280 patch, scsi-ml still sends chaining sg
> > > list. So it doesn't work.
> > >
> > > The following patch disables chaining sg list for qla1280. If the fix
> > > that I've just sent doesn't work, please try this.
> >
> > Ok, the other patch _did_ work, but this got tested anyhow and it did
> > _not_ fix things.
> >
> 
> Sorry to confirm this. My RAID5 got destroyed a second time.
> To summarize what worked / not worked / and seems to work for me:
> 
> First 2 tries with unpatched rc4-mm1: Both times one sata_sil24-drive got 
> kicked
> Then I switched back to rc3-mm1, 18 boots with that kernel worked.
> Then I tried the patched rc4-mm1 and it worked too.
> The next boot also worked, but the third time kicked a drive out again.
> But as nobody reads logs, I did not notice that and keep using the
> patched rc4-mm1.
> The next 5 times the system worked normally with the two remaining drives.
> The sixth boot kicked the second sata_sil24 drive. That I did notice...
> After reassembling the RAID, I'm now back to the patch rc4-mm1 that
> did boot correctly this time.
> So the patch just makes it unlikelier to hit the bug. Instead of
> failing 2 out of 2 times, it only failed 2 out of 8 times.
> I compared the rc4-mm1 boot from a working case and the case where it
> kicked the first drive. Nothing seems to stand out...
> 
> < == good rc4-mm1 boot
> > == bad rc4-mm1 boot that kicked the drive
> 
> 145c145
> < CPU 0: aperture @ 400 size 32 MB
> ---
> > CPU 0: aperture @ b7f000 size 32 MB
> 154c154
> < Calibrating delay using timer specific routine.. 5203.23 BogoMIPS
> (lpj=26016160)
> ---
> > Calibrating delay using timer specific routine.. 5203.22 BogoMIPS 
> > (lpj=26016138)
> 169c169
> < APIC timer calibration result 1248
> ---
> > APIC timer calibration result 1244
> 173c173
> < Calibrating delay using timer specific routine.. 5222.40 BogoMIPS
> (lpj=26112010)
> ---
> > Calibrating delay using timer specific routine.. 5200.01 BogoMIPS 
> > (lpj=2652)
> 182c182
> < Calibrating delay using timer specific routine.. 5222.73 BogoMIPS
> (lpj=26113694)
> ---
> > Calibrating delay using timer specific routine.. 5200.01 BogoMIPS 
> > (lpj=2681)
> 191c191
> < Calibrating delay using timer specific routine.. 5223.07 BogoMIPS
> (lpj=26115369)
> ---
> > Calibrating delay using timer specific routine.. 5200.03 BogoMIPS 
> > (lpj=26000164)
> 269d268
> < Switched to high resolution mode on CPU 3
> 270a270
> > Switched to high resolution mode on CPU 3
> 502,509c502,509
> < raid6: int64x1   2634 MB/s
> < raid6: int64x2   3244 MB/s
> < raid6: int64x4   3405 MB/s
> < raid6: int64x8   2614 MB/s
> < raid6: sse2x13607 MB/s
> < raid6: sse2x24834 MB/s
> < raid6: sse2x44946 MB/s
> < raid6: using algorithm sse2x4 (4946 MB/s)
> ---
> > raid6: int64x1   2680 MB/s
> > raid6: int64x2   3232 MB/s
> > raid6: int64x4   3411 MB/s
> > raid6: int64x8   2620 MB/s
> > raid6: sse2x13606 MB/s
> > raid6: sse2x24810 MB/s
> > raid6: sse2x44910 MB/s
> > raid6: using algorithm sse2x4 (4910 MB/s)
> 567c567
> < md1: bitmap initialized from disk: read 10/10 pages, set 96 bits
> ---
> > md1: bitmap initialized from disk: read 10/10 pages, set 104 bits
> 568a569,655
> > ata1.00: exception Emask 0x20 SAct 0x1 SErr 0x0 action 0x2
> > ata1.00: irq_stat 0x00020002, PCI master abort while fetching SGT
> > ata1.00: cmd 61/08:00:09:d6:42/00:00:25:00:00/40 tag 0 cdb 0x0 data 4096 out
> >  res 50/00:00:af:ea:42/00:00:25:00:00/e0 Emask 0x20 (host bus error)
> > ata1.00: status: {DRDY }
> > ata1: soft resetting link
> > ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> > ata1.00: configured for UDMA/100
> > ata1: EH complete
> > sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors (320073 MB)
> > sd 0:0:0:0: [sda] Write Protect is off
> > sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> > sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't 
> > support DPO or FUA
> > ata1.00: exception Emask 0x20 SAct 0x1 SErr 0x0 action 0x2
> > ata1.00: irq_stat 0x00020002, PCI master abort while fetching SGT
> > ata1.00: cmd 61/08:00:09:d6:42/00:00:25:00:00/40 tag 0 cdb 0x0 data 4096 out
> >  res 50/00:00:af:ea:42/00:00:25:00:00/e0 Emask 0x20 (host bus error)
> > ata1.00: status: {DRDY }
> > ata1: soft resetting link
> > ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> > ata1.00: configured for UDMA/100
> > ata1: EH complete
> > sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors (320073 MB)
> > sd 0:0:0:0: [sda] Write Protect is off
> > sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> > sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't 
> > support DPO or FUA
> > ata1.00: exception Emask 0x20 SAct 0x1 SErr 0x0 action 0x2
> > ata1.

Re: [PATCH] SCSI: update Kconfig help text to indicate SCSI core's widespread usage

2007-09-14 Thread Stefan Richter
On 14 Sep, Lennart Sorensen wrote:
> On Fri, Sep 14, 2007 at 06:01:53PM +0200, Stefan Richter wrote:
...
>> +  - for non-SCSI hardware whose drivers translate from and to SCSI
>> +protocols, like the IDE-SCSI emulation driver and most notably
>> +for all SATA drivers.
...
> You left out PATA running libata drivers.  Not just SATA is affected
> there.  Looks pretty decent otherwise.


From: Stefan Richter <[EMAIL PROTECTED]>
Subject: SCSI: update Kconfig help text to indicate SCSI core's widespread usage

Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
 drivers/scsi/Kconfig |   32 
 1 file changed, 20 insertions(+), 12 deletions(-)

Index: linux-2.6.23-rc6/drivers/scsi/Kconfig
===
--- linux-2.6.23-rc6.orig/drivers/scsi/Kconfig
+++ linux-2.6.23-rc6/drivers/scsi/Kconfig
@@ -12,23 +12,31 @@ config SCSI
depends on BLOCK
select SCSI_DMA if HAS_DMA
---help---
- If you want to use a SCSI hard disk, SCSI tape drive, SCSI CD-ROM or
- any other SCSI device under Linux, say Y and make sure that you know
- the name of your SCSI host adapter (the card inside your computer
- that "speaks" the SCSI protocol, also called SCSI controller),
- because you will be asked for it.
-
- You also need to say Y here if you have a device which speaks
- the SCSI protocol.  Examples of this include the parallel port
- version of the IOMEGA ZIP drive, USB storage devices, Fibre
- Channel, FireWire storage and the IDE-SCSI emulation driver.
+ This option enables core support for SCSI protocols.
+ You need it
+ - for classic parallel SCSI hardware,
+ - for newer SCSI transports such as Fibre Channel, FireWire storage,
+   or iSCSI,
+ - for non-SCSI hardware which speaks SCSI protocols, such as USB
+   storage devices or the parallel port version of Iomega Zip drive,
+ - for non-SCSI hardware whose drivers translate from and to SCSI
+   protocols, most notably all Serial ATA drivers, and Parallel ATA
+   via the ATA configuration option.
 
  To compile this driver as a module, choose M here and read
  .
  The module will be called scsi_mod.
 
  However, do not compile this as a module if your root file system
- (the one containing the directory /) is located on a SCSI device.
+ (the one containing the directory /) is located on a SCSI device
+ or on a device whose driver represents it as SCSI device, as
+ indicated above.  Choose Y in this case, or set up an initrd.
+
+ Subsequent options in this menu enable specific SCSI command set
+ support for harddisks, CD/DVD-ROM/R/W, tapes etc..  This menu also
+ presents options for specific SCSI controllers, while options for
+ some other SCSI transports and all non-SCSI controllers are located
+ in other menus (SATA, USB, FireWire etc.).
 
 config SCSI_DMA
bool
@@ -120,7 +128,7 @@ config BLK_DEV_SR
tristate "SCSI CDROM support"
depends on SCSI
---help---
- If you want to use a SCSI or FireWire CD-ROM under Linux,
+ If you want to use a SCSI, SATA, USB or FireWire CD-ROM or DVD-ROM,
  say Y and read the SCSI-HOWTO and the CDROM-HOWTO at
  . Also make sure to say
  Y or M to "ISO 9660 CD-ROM file system support" later.

-- 
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: CONFIG_BLK_DEV_BSG=n

2007-09-14 Thread James Bottomley
On Fri, 2007-09-14 at 12:50 -0700, Medve Emilian-EMMEDVE1 wrote:
> Which solution would you be more comfortable with?

The one which is currently in -mm is this one:

http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commit;h=49892223f7d3a2333ef9e6cbdd526676e1fc517a

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


CONFIG_BLK_DEV_BSG=n

2007-09-14 Thread Medve Emilian-EMMEDVE1
Hello,


I'm trying to get powerpc to build without block device support
(CONFIG_BLOCK=n). I'm getting the following errors:

  CC  arch/powerpc/kernel/setup_32.o
In file included from include/linux/blkdev.h:17,
 from include/linux/ide.h:13,
 from arch/powerpc/kernel/setup_32.c:13:
include/linux/bsg.h:67: warning: 'struct request_queue' declared inside
parameter list
include/linux/bsg.h:67: warning: its scope is only this definition or
declaration, which is probably not what you want
include/linux/bsg.h:71: warning: 'struct request_queue' declared inside
parameter list
In file included from arch/powerpc/kernel/setup_32.c:13:
include/linux/ide.h:857: error: field 'wrq' has incomplete type

  CC  arch/powerpc/kernel/ppc_ksyms.o
In file included from include/linux/blkdev.h:17,
 from include/linux/ide.h:13,
 from arch/powerpc/kernel/ppc_ksyms.c:15:
include/linux/bsg.h:67: warning: 'struct request_queue' declared inside
parameter list
include/linux/bsg.h:67: warning: its scope is only this definition or
declaration, which is probably not what you want
include/linux/bsg.h:71: warning: 'struct request_queue' declared inside
parameter list
In file included from arch/powerpc/kernel/ppc_ksyms.c:15:
include/linux/ide.h:857: error: field 'wrq' has incomplete type

I fixed the errors with a small patch in the powerpc code only and I'm
comfortable with that. The matter I wanted your input on is the warnings
from bsg.h coming from this are of the file:

...
#ifdef __KERNEL__

#if defined(CONFIG_BLK_DEV_BSG)
struct bsg_class_device {
struct class_device *class_dev;
struct device *dev;
int minor;
struct request_queue *queue;
};

extern int bsg_register_queue(struct request_queue *, struct device *,
const char *);
extern void bsg_unregister_queue(struct request_queue *);
#else
static inline int bsg_register_queue(struct request_queue * rq, struct
device *dev, const char *name
)
{
return 0;
}
static inline void bsg_unregister_queue(struct request_queue *rq)
{
}
#endif

#endif /* __KERNEL__ */
...

I noticed that the '#else' branch was last updated by James (a4ee0df8)
in order to address some other warnings in scsi_sysfs.c, for example, in
the next piece of code:

...
error = bsg_register_queue(rq, &sdev->sdev_gendev, NULL);

if (error)
sdev_printk(KERN_INFO, sdev,
"Failed to register bsg queue, errno=%d\n",
error);

/* we're treating error on bsg register as non-fatal, so pretend
 * nothing went wrong */
error = 0;
...

The quick fix to those warnings is to add a declaration of struct
request_queue in bsg.h something looking like this:

...
#ifdef __KERNEL__

struct request_queue; <- This is the addition

#if defined(CONFIG_BLK_DEV_BSG)
struct bsg_class_device {
struct class_device *class_dev;
...

However, I was wondering if there isn't a cleaner way of doing it. For
example, from the comments in scsi_sysfs.c it looks like it would be
possible not to call bsg_register_queue() at all when
CONFIG_BLK_DEV_BSG=n and get rid of the '#else' branch in bsg.h as I
don't think bsg_register_queue() and bsg_unregister_queue() should be
called when CONFIG_BLK_DEV_BSG=n.

Which solution would you be more comfortable with?


Thanks,
Emil.


This e-mail, and any associated attachments have been classified as:

[ ] Public
[x] Freescale Semiconductor Internal Use Only
[ ] Freescale Semiconductor Confidential Proprietary
-
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 PATCH] SCSI: split Kconfig menu into two

2007-09-14 Thread Adrian Bunk
On Fri, Sep 14, 2007 at 09:00:33PM +0200, Sam Ravnborg wrote:
> Hi Stefan.
> 
> Such a patch really calls for some minimal unifacation among
> the architectures.
> 
> > 
> >  arch/alpha/Kconfig|2 
> >  arch/arm/Kconfig  |2 
> >  arch/avr32/Kconfig|2 
> >  arch/blackfin/Kconfig |2 
> >  arch/cris/Kconfig |2 
> >  arch/frv/Kconfig  |2 
> >  arch/i386/Kconfig |2 
> >  arch/ia64/Kconfig |2 
> >  arch/m32r/Kconfig |2 
> >  arch/m68k/Kconfig |2 
> >  arch/m68knommu/Kconfig|2 
> >  arch/mips/Kconfig |2 
> >  arch/parisc/Kconfig   |2 
> >  arch/powerpc/Kconfig  |2 
> >  arch/ppc/Kconfig  |2 
> >  arch/s390/Kconfig |2 
> >  arch/sh/Kconfig   |2 
> >  arch/sh64/Kconfig |2 
> >  arch/sparc/Kconfig|2 
> >  arch/sparc64/Kconfig  |2 
> >  arch/um/Kconfig   |2 
> >  arch/v850/Kconfig |2 
> >  arch/x86_64/Kconfig   |4 
> >  arch/xtensa/Kconfig   |2 
> 
> 
> Exactly the same change for all architectures.
> IT would be good to introduce a common file that contains
> some of the shared stuff from the different architectures.
> We could start out simple with:
> 
> arch/Kconfig.arch:
>...

Stefan simply shouldn't move it out of drivers/Kconfig.

>   Sam

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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


Power management for SCSI transports

2007-09-14 Thread Alan Stern
Kristen:

You've been doing a lot of work on link power management for SCSI
buses.  It would be good if we could integrate this with the USB
power-management implementation in the usb-storage driver -- but I'm
not sure whether our requirements and feature sets really match up.

I'm not at all familiar with what you've already done.  From my point
of view, what's needed is a way for the SCSI core to tell a lower-level
driver that all the devices on its bus are safely quiescent and it's
okay to put the HBA & transport into a power-saving state.  (For
example, the higher layers would have to insure that disk heads are
parked and drives spun down, if needed.)  It might be nice to have a
callback for the converse situation also, but this doesn't seem
necessary since the LLD can go back to full power on demand.

(The same approach ought to work with non-USB transports, but I'll
stick to what I know about.)

Does this mesh well with your current designs?

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC PATCH] SCSI: split Kconfig menu into two

2007-09-14 Thread Sam Ravnborg
Hi Stefan.

Such a patch really calls for some minimal unifacation among
the architectures.

> 
>  arch/alpha/Kconfig|2 
>  arch/arm/Kconfig  |2 
>  arch/avr32/Kconfig|2 
>  arch/blackfin/Kconfig |2 
>  arch/cris/Kconfig |2 
>  arch/frv/Kconfig  |2 
>  arch/i386/Kconfig |2 
>  arch/ia64/Kconfig |2 
>  arch/m32r/Kconfig |2 
>  arch/m68k/Kconfig |2 
>  arch/m68knommu/Kconfig|2 
>  arch/mips/Kconfig |2 
>  arch/parisc/Kconfig   |2 
>  arch/powerpc/Kconfig  |2 
>  arch/ppc/Kconfig  |2 
>  arch/s390/Kconfig |2 
>  arch/sh/Kconfig   |2 
>  arch/sh64/Kconfig |2 
>  arch/sparc/Kconfig|2 
>  arch/sparc64/Kconfig  |2 
>  arch/um/Kconfig   |2 
>  arch/v850/Kconfig |2 
>  arch/x86_64/Kconfig   |4 
>  arch/xtensa/Kconfig   |2 


Exactly the same change for all architectures.
IT would be good to introduce a common file that contains
some of the shared stuff from the different architectures.
We could start out simple with:

arch/Kconfig.arch:

source "net/Kconfig"
source "drivers/Kconfig"
source "fs/Kconfig"
source "security/Kconfig"
source "crypto/Kconfig"
source "lib/Kconfig"


And then source it in all relevant arch Kconfig files.
It is not all that can use it but most do.
A trivial task but one small step towards unification between
the architectures on the Kconfig level.

Sam
-
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: update Kconfig help text to indicate SCSI core's widespread usage

2007-09-14 Thread Lennart Sorensen
On Fri, Sep 14, 2007 at 06:01:53PM +0200, Stefan Richter wrote:
> Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
> ---
> 
> Applicable to 2.6.23-rc6 and to scsi-misc.
> 
>  drivers/scsi/Kconfig |   32 
>  1 file changed, 20 insertions(+), 12 deletions(-)
> 
> Index: linux-2.6.23-rc6/drivers/scsi/Kconfig
> ===
> --- linux-2.6.23-rc6.orig/drivers/scsi/Kconfig
> +++ linux-2.6.23-rc6/drivers/scsi/Kconfig
> @@ -12,23 +12,31 @@ config SCSI
>   depends on BLOCK
>   select SCSI_DMA if HAS_DMA
>   ---help---
> -   If you want to use a SCSI hard disk, SCSI tape drive, SCSI CD-ROM or
> -   any other SCSI device under Linux, say Y and make sure that you know
> -   the name of your SCSI host adapter (the card inside your computer
> -   that "speaks" the SCSI protocol, also called SCSI controller),
> -   because you will be asked for it.
> -
> -   You also need to say Y here if you have a device which speaks
> -   the SCSI protocol.  Examples of this include the parallel port
> -   version of the IOMEGA ZIP drive, USB storage devices, Fibre
> -   Channel, FireWire storage and the IDE-SCSI emulation driver.
> +   This option enables core support for SCSI protocols.
> +   You need it
> +   - for classic parallel SCSI hardware,
> +   - for newer SCSI transports such as Fibre Channel, FireWire storage,
> + or iSCSI,
> +   - for non-SCSI hardware which speaks SCSI protocols, such as USB
> + storage devices or the parallel port version of Iomega Zip drive,
> +   - for non-SCSI hardware whose drivers translate from and to SCSI
> + protocols, like the IDE-SCSI emulation driver and most notably
> + for all SATA drivers.
>  
> To compile this driver as a module, choose M here and read
> .
> The module will be called scsi_mod.
>  
> However, do not compile this as a module if your root file system
> -   (the one containing the directory /) is located on a SCSI device.
> +   (the one containing the directory /) is located on a SCSI device
> +   or on a device whose driver represents it as SCSI device, as
> +   indicated above.  Choose Y in this case, or set up an initrd.
> +
> +   Subsequent options in this menu enable specific SCSI command set
> +   support for harddisks, CD/DVD-ROM/R/W, tapes etc..  This menu also
> +   presents options for specific SCSI controllers, while options for
> +   some other SCSI transports and all non-SCSI controllers are located
> +   in other menus (SATA, USB, FireWire etc.).
>  
>  config SCSI_DMA
>   bool
> @@ -120,7 +128,7 @@ config BLK_DEV_SR
>   tristate "SCSI CDROM support"
>   depends on SCSI
>   ---help---
> -   If you want to use a SCSI or FireWire CD-ROM under Linux,
> +   If you want to use a SCSI, SATA, USB or FireWire CD-ROM or DVD-ROM,
> say Y and read the SCSI-HOWTO and the CDROM-HOWTO at
> . Also make sure to say
> Y or M to "ISO 9660 CD-ROM file system support" later.

You left out PATA running libata drivers.  Not just SATA is affected
there.  Looks pretty decent otherwise.

--
Len Sorensen
-
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] aic94xx: fix smartctl utility problem

2007-09-14 Thread Jeff Garzik

Gilbert Wu wrote:

Fixed the problem that "smartctl -a /dev/some_sata_disk -d ata"  does
not work on SATA device. ( The smartctl v5.38 does need "-d ata"
option.)
  The aic94xx need to return ATA output register for all ATA commands
except ATA Read/Write commands.
  The aic94xx also mark out the DRQ bit from status register which is
treated as AC_ERR_HSM (host state machine violation) error by top layer
if it set to one.
 The firmware of aic94xx chip handle all ATA handshaking, data transfer
and return ATA output register which is sent by the device.  So the DRQ
bit may not reflect the last state of device when the command finished
and it is no meaning for the caller.

Signed-off-by: Gilbert Wu <[EMAIL PROTECTED]>


ACK


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] SCSI: trailing whitespace in Kconfig

2007-09-14 Thread Stefan Richter
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---

Applies after patch "SCSI: split Kconfig menu into two".
I didn't want to change whitespace in the portions that this patch
moved from drivers/scsi/Kconfig to drivers/scsi/Kconfig.lowlevel,
hence produced this follow-up.


 drivers/scsi/Kconfig.lowlevel |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

Index: linux-2.6.23-rc6/drivers/scsi/Kconfig.lowlevel
===
--- linux-2.6.23-rc6.orig/drivers/scsi/Kconfig.lowlevel
+++ linux-2.6.23-rc6/drivers/scsi/Kconfig.lowlevel
@@ -252,7 +252,7 @@ config SCSI_DPT_I2O
tristate "Adaptec I2O RAID support "
depends on !64BIT && SCSI && PCI && VIRT_TO_BUS
help
- This driver supports all of Adaptec's I2O based RAID controllers as 
+ This driver supports all of Adaptec's I2O based RAID controllers as
  well as the DPT SmartRaid V cards.  This is an Adaptec maintained
  driver by Deanna Bonds.  See .
 
@@ -457,7 +457,7 @@ config SCSI_GDTH
---help---
  Formerly called GDT SCSI Disk Array Controller Support.
 
- This is a driver for RAID/SCSI Disk Array Controllers (EISA/ISA/PCI) 
+ This is a driver for RAID/SCSI Disk Array Controllers (EISA/ISA/PCI)
  manufactured by Intel Corporation/ICP vortex GmbH. It is documented
  in the kernel source in  and
  
@@ -491,7 +491,7 @@ config SCSI_GENERIC_NCR5380_MMIO
select SCSI_SPI_ATTRS
---help---
  This is a driver for the old NCR 53c80 series of SCSI controllers
- on boards using memory mapped I/O. 
+ on boards using memory mapped I/O.
  It is explained in section 3.8 of the SCSI-HOWTO, available from
  .  If it doesn't work out
  of the box, you may have to change some settings in
@@ -1261,7 +1261,7 @@ config SCSI_DEBUG
  each with multiple dummy SCSI devices (disks). It defaults to one
  host adapter with one dummy SCSI disk. Each dummy disk uses kernel
  RAM as storage (i.e. it is a ramdisk). To save space when multiple
- dummy disks are simulated, they share the same kernel RAM for 
+ dummy disks are simulated, they share the same kernel RAM for
  their storage. See  for more
  information. This driver is primarily of use to those testing the
  SCSI and block subsystems. If unsure, say N.

-- 
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] aic94xx: fix smartctl utility problem

2007-09-14 Thread Gilbert Wu
Fixed the problem that "smartctl -a /dev/some_sata_disk -d ata"  does
not work on SATA device. ( The smartctl v5.38 does need "-d ata"
option.)
  The aic94xx need to return ATA output register for all ATA commands
except ATA Read/Write commands.
  The aic94xx also mark out the DRQ bit from status register which is
treated as AC_ERR_HSM (host state machine violation) error by top layer
if it set to one.
 The firmware of aic94xx chip handle all ATA handshaking, data transfer
and return ATA output register which is sent by the device.  So the DRQ
bit may not reflect the last state of device when the command finished
and it is no meaning for the caller.

Signed-off-by: Gilbert Wu <[EMAIL PROTECTED]>

diff -urN a/drivers/scsi/aic94xx/aic94xx_task.c
b/drivers/scsi/aic94xx/aic94xx_task.c
--- a/drivers/scsi/aic94xx/aic94xx_task.c   2007-09-13 04:46:00.0 
-0700
+++ b/drivers/scsi/aic94xx/aic94xx_task.c   2007-09-14 06:06:52.0 
-0700
@@ -25,6 +25,7 @@
  */
 
 #include 
+#include 
 #include "aic94xx.h"
 #include "aic94xx_sas.h"
 #include "aic94xx_hwi.h"
@@ -220,6 +221,7 @@
memcpy(&resp->ending_fis[0], r+16, 24);
ts->buf_valid_size = sizeof(*resp);
}
+   resp->ending_fis[2] &= ~ATA_DRQ;
}
 
asd_invalidate_edb(escb, edb_id);
@@ -257,6 +259,11 @@
ts->stat = SAS_PROTO_RESPONSE;
asd_get_response_tasklet(ascb, dl);
break;
+   case TC_CSMI:
+   ts->resp = SAS_TASK_COMPLETE;
+   ts->stat = SAM_GOOD;
+   asd_get_response_tasklet(ascb, dl);
+   break;
case TF_OPEN_REJECT:
ts->resp = SAS_TASK_UNDELIVERED;
ts->stat = SAS_OPEN_REJECT;
@@ -374,7 +381,32 @@
 }
 
 /* -- ATA -- */
+int is_ata_rw_cmd(u8 ata_cmd)
+{
 
+   switch (ata_cmd) {
+   case ATA_CMD_READ:
+   case ATA_CMD_READ_EXT:
+   case ATA_CMD_WRITE:
+   case ATA_CMD_WRITE_EXT:
+   case ATA_CMD_WRITE_FUA_EXT:
+   case ATA_CMD_FPDMA_READ:
+   case ATA_CMD_FPDMA_WRITE:
+   case ATA_CMD_PIO_READ:
+   case ATA_CMD_PIO_READ_EXT:
+   case ATA_CMD_PIO_WRITE:
+   case ATA_CMD_PIO_WRITE_EXT:
+   case ATA_CMD_READ_MULTI:
+   case ATA_CMD_READ_MULTI_EXT:
+   case ATA_CMD_WRITE_MULTI:
+   case ATA_CMD_WRITE_MULTI_EXT:
+   case ATA_CMD_WRITE_MULTI_FUA_EXT:
+   case ATA_CMD_VERIFY:
+   case ATA_CMD_VERIFY_EXT:
+   return 1;
+   }
+   return 0;
+}
 static int asd_build_ata_ascb(struct asd_ascb *ascb, struct sas_task *task,
  gfp_t gfp_flags)
 {
@@ -427,6 +459,9 @@
flags |= STP_AFFIL_POLICY;
scb->ata_task.flags = flags;
}
+   if (!is_ata_rw_cmd(scb->ata_task.fis.command))
+   scb->ata_task.ata_flags |= CSMI_TASK;
+
ascb->tasklet_complete = asd_task_tasklet_complete;
 
if (likely(!task->ata_task.device_control_reg_update))


-
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] aic94xx: fix smartctl utility problem

2007-09-14 Thread Wu, Gilbert
HI Jeff,
  
Oops! I missed that one and will resend again.

Thanks!
Gilbert

-Original Message-
From: Jeff Garzik [mailto:[EMAIL PROTECTED] 
Sent: Friday, September 14, 2007 10:27 AM
To: Wu, Gilbert
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH] aic94xx: fix smartctl utility problem

Gilbert Wu wrote:
> Fixed the problem that "smartctl -a /dev/some_sata_disk -d ata"  does
> not work on SATA device. ( The smartctl v5.38 does need "-d ata"
> option.)
>   The aic94xx need to return ATA output register for all ATA commands
> except ATA Read/Write commands.
>   The aic94xx also mark out the DRQ bit from status register which is
> treated as AC_ERR_HSM (host state machine violation) error by top
layer
> if it set to one.
>  The firmware of aic94xx chip handle all ATA handshaking, data
transfer
> and return ATA output register which is sent by the device.  So the
DRQ
> bit may not reflect the last state of device when the command finished
> and it is no meaning for the caller.
> 
> Signed-off-by: Gilbert Wu <[EMAIL PROTECTED]>

ACK, thanks for your patience


> @@ -427,6 +459,9 @@
>   flags |= STP_AFFIL_POLICY;
>   scb->ata_task.flags = flags;
>   }
> + if (!is_ata_rw_cmd(scb->ata_task.fis.command))
> + scb->ata_task.ata_flags|=CSMI_TASK;

Minor style complaint:  add spaces around "|="

Regards,

Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] aic94xx: fix smartctl utility problem

2007-09-14 Thread Jeff Garzik

Gilbert Wu wrote:

Fixed the problem that "smartctl -a /dev/some_sata_disk -d ata"  does
not work on SATA device. ( The smartctl v5.38 does need "-d ata"
option.)
  The aic94xx need to return ATA output register for all ATA commands
except ATA Read/Write commands.
  The aic94xx also mark out the DRQ bit from status register which is
treated as AC_ERR_HSM (host state machine violation) error by top layer
if it set to one.
 The firmware of aic94xx chip handle all ATA handshaking, data transfer
and return ATA output register which is sent by the device.  So the DRQ
bit may not reflect the last state of device when the command finished
and it is no meaning for the caller.

Signed-off-by: Gilbert Wu <[EMAIL PROTECTED]>


ACK, thanks for your patience



@@ -427,6 +459,9 @@
flags |= STP_AFFIL_POLICY;
scb->ata_task.flags = flags;
}
+   if (!is_ata_rw_cmd(scb->ata_task.fis.command))
+   scb->ata_task.ata_flags|=CSMI_TASK;


Minor style complaint:  add spaces around "|="

Regards,

Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] aic94xx: fix smartctl utility problem

2007-09-14 Thread Gilbert Wu
Fixed the problem that "smartctl -a /dev/some_sata_disk -d ata"  does
not work on SATA device. ( The smartctl v5.38 does need "-d ata"
option.)
  The aic94xx need to return ATA output register for all ATA commands
except ATA Read/Write commands.
  The aic94xx also mark out the DRQ bit from status register which is
treated as AC_ERR_HSM (host state machine violation) error by top layer
if it set to one.
 The firmware of aic94xx chip handle all ATA handshaking, data transfer
and return ATA output register which is sent by the device.  So the DRQ
bit may not reflect the last state of device when the command finished
and it is no meaning for the caller.

Signed-off-by: Gilbert Wu <[EMAIL PROTECTED]>


diff -urN a/drivers/scsi/aic94xx/aic94xx_task.c 
b/drivers/scsi/aic94xx/aic94xx_task.c
--- a/drivers/scsi/aic94xx/aic94xx_task.c   2007-09-13 04:46:00.0 
-0700
+++ b/drivers/scsi/aic94xx/aic94xx_task.c   2007-09-13 04:46:31.0 
-0700
@@ -25,6 +25,7 @@
  */
 
 #include 
+#include 
 #include "aic94xx.h"
 #include "aic94xx_sas.h"
 #include "aic94xx_hwi.h"
@@ -220,6 +221,7 @@
memcpy(&resp->ending_fis[0], r+16, 24);
ts->buf_valid_size = sizeof(*resp);
}
+   resp->ending_fis[2] &= ~ATA_DRQ;
}
 
asd_invalidate_edb(escb, edb_id);
@@ -257,6 +259,11 @@
ts->stat = SAS_PROTO_RESPONSE;
asd_get_response_tasklet(ascb, dl);
break;
+   case TC_CSMI:
+   ts->resp = SAS_TASK_COMPLETE;
+   ts->stat = SAM_GOOD;
+   asd_get_response_tasklet(ascb, dl);
+   break;
case TF_OPEN_REJECT:
ts->resp = SAS_TASK_UNDELIVERED;
ts->stat = SAS_OPEN_REJECT;
@@ -374,7 +381,32 @@
 }
 
 /* -- ATA -- */
+int is_ata_rw_cmd(u8 ata_cmd)
+{
 
+   switch (ata_cmd) {
+   case ATA_CMD_READ:
+   case ATA_CMD_READ_EXT:
+   case ATA_CMD_WRITE:
+   case ATA_CMD_WRITE_EXT:
+   case ATA_CMD_WRITE_FUA_EXT:
+   case ATA_CMD_FPDMA_READ:
+   case ATA_CMD_FPDMA_WRITE:
+   case ATA_CMD_PIO_READ:
+   case ATA_CMD_PIO_READ_EXT:
+   case ATA_CMD_PIO_WRITE:
+   case ATA_CMD_PIO_WRITE_EXT:
+   case ATA_CMD_READ_MULTI:
+   case ATA_CMD_READ_MULTI_EXT:
+   case ATA_CMD_WRITE_MULTI:
+   case ATA_CMD_WRITE_MULTI_EXT:
+   case ATA_CMD_WRITE_MULTI_FUA_EXT:
+   case ATA_CMD_VERIFY:
+   case ATA_CMD_VERIFY_EXT:
+   return 1;
+   }
+   return 0;
+}
 static int asd_build_ata_ascb(struct asd_ascb *ascb, struct sas_task *task,
  gfp_t gfp_flags)
 {
@@ -427,6 +459,9 @@
flags |= STP_AFFIL_POLICY;
scb->ata_task.flags = flags;
}
+   if (!is_ata_rw_cmd(scb->ata_task.fis.command))
+   scb->ata_task.ata_flags|=CSMI_TASK;
+
ascb->tasklet_complete = asd_task_tasklet_complete;
 
if (likely(!task->ata_task.device_control_reg_update))



-
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: sata & scsi suggestion for make menuconfig

2007-09-14 Thread Stefan Richter
Adrian Bunk wrote:
> On Fri, Sep 14, 2007 at 05:37:37PM +0200, Stefan Richter wrote:
>> In
>> practice, this takes too much time, hence you take an existing .config
>> (yours or somebody else's) and go from there.
> 
> Kconfig let's you start with the defconfig when doing "make menuconfig" 
> without any .config present,
[...]

This is one of those "somebody else's .config".

>> Whenever one enables an option for the first time, it would IMO be
>> foolish to ignore its help text.
> 
> Then the number of non-foolish users is quite near to 0...

Perhaps.  Although I meant only options which one enables oneself, not
options which are taken over from somebody else's .config.

> If you expect people to read several hundreds or thousands of help texts 
> only for configuring a kernel then you are expecting something that is 
> simply not realistic.
> 
> It is intuitive for a user to enable the "Serial ATA" menu and he might 
> not expect to have to read the help text when he has SATA drivers, while 
> having to enable anything in the "SCSI device support" menu is highly 
> unintuitively when the user does not have SCSI hardware.

It surely is unintuitive, and it is one of the worse cases where the
current menu layout is unintuitive.  We have to improve that, even
though it is ultimately impossible to serve everyone's needs equally
well or, generally, make kernel configuration a piece of cake.

Note though, some suggestions which came up here don't actually make the
menus more intuitive.  Notably the patch "Select BLK_DEV_SD for all
SCSI/libata drivers" is counterintuitive in a different color:  It
follows the philosophy of "I know what's good for you and I act on your
behalf behind your back --- trust me, it's for your best".

I too am guilty of proposing the usage of 'select'
(http://lkml.org/lkml/2007/9/8/9) but I suggested a variant which lets
the user stay informed and in control (as far as this is possible with
'select' which always increases complexity, never reduces it).

But rather than adding multiple menu items which enable the same option,
a reorganization of the menus which better reflect the role of SCSI core
and SCSI highlevel might be more effective --- similar to "Networking"
which is separate from "Network device support"
(http://lkml.org/lkml/2007/9/10/5, http://lkml.org/lkml/2007/9/10/115).
-- 
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] SCSI: update Kconfig help text to indicate SCSI core's widespread usage

2007-09-14 Thread Jeff Garzik

Stefan Richter wrote:

Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---

Applicable to 2.6.23-rc6 and to scsi-misc.

 drivers/scsi/Kconfig |   32 
 1 file changed, 20 insertions(+), 12 deletions(-)


ACK


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: sata & scsi suggestion for make menuconfig

2007-09-14 Thread Adrian Bunk
On Fri, Sep 14, 2007 at 05:37:37PM +0200, Stefan Richter wrote:
> Adrian Bunk wrote:
> > On Fri, Sep 14, 2007 at 04:54:07PM +0200, Stefan Richter wrote:
> >> The patch which is discussed here is specifically targeted towards users
> >> who are convinced that they can migrate to different drivers without
> >> reading Kconfig help texts.
> > 
> > Nothing about the patch is only about migration.
> > 
> > The same applies if you configure a kernel from scratch.
> > 
> > Do "make menuconfig" with the .config you are normally using, count the 
> > number of options that are visible, and ask yourself whether we can 
> > really expect users to read the help texts for every single option shown.
> > 
> > People mostly read help texts for options where they don't understand 
> > what this option is about - and "Serial ATA" therefore is an option that 
> > is likely to get enabled without the user looking at the help text.
> 
> If you create .config from scratch, then you can get away without
> reading help texts if you have a target with minimal hardware and
> protocols requirements and you know all the subsystems involved.
> 
> In all other cases, you theoretically need to read all help texts (minus
> the ones that don't appear because you deselect entire subsystems).  In
> practice, this takes too much time, hence you take an existing .config
> (yours or somebody else's) and go from there.

Kconfig let's you start with the defconfig when doing "make menuconfig" 
without any .config present, so in practice users start from the 
defconfig and then go through all menus at once enabling and disabling 
options to adapt the configurations to their needs.

Or they start from the "includes everything" .config of their 
distribution and remove everything they don't need.

> Whenever one enables an option for the first time, it would IMO be
> foolish to ignore its help text.

Then the number of non-foolish users is quite near to 0...

If you expect people to read several hundreds or thousands of help texts 
only for configuring a kernel then you are expecting something that is 
simply not realistic.

It is intuitive for a user to enable the "Serial ATA" menu and he might 
not expect to have to read the help text when he has SATA drivers, while 
having to enable anything in the "SCSI device support" menu is highly 
unintuitively when the user does not have SCSI hardware.

> Stefan Richter

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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: update Kconfig help text to indicate SCSI core's widespread usage

2007-09-14 Thread Stefan Richter
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---

Applicable to 2.6.23-rc6 and to scsi-misc.

 drivers/scsi/Kconfig |   32 
 1 file changed, 20 insertions(+), 12 deletions(-)

Index: linux-2.6.23-rc6/drivers/scsi/Kconfig
===
--- linux-2.6.23-rc6.orig/drivers/scsi/Kconfig
+++ linux-2.6.23-rc6/drivers/scsi/Kconfig
@@ -12,23 +12,31 @@ config SCSI
depends on BLOCK
select SCSI_DMA if HAS_DMA
---help---
- If you want to use a SCSI hard disk, SCSI tape drive, SCSI CD-ROM or
- any other SCSI device under Linux, say Y and make sure that you know
- the name of your SCSI host adapter (the card inside your computer
- that "speaks" the SCSI protocol, also called SCSI controller),
- because you will be asked for it.
-
- You also need to say Y here if you have a device which speaks
- the SCSI protocol.  Examples of this include the parallel port
- version of the IOMEGA ZIP drive, USB storage devices, Fibre
- Channel, FireWire storage and the IDE-SCSI emulation driver.
+ This option enables core support for SCSI protocols.
+ You need it
+ - for classic parallel SCSI hardware,
+ - for newer SCSI transports such as Fibre Channel, FireWire storage,
+   or iSCSI,
+ - for non-SCSI hardware which speaks SCSI protocols, such as USB
+   storage devices or the parallel port version of Iomega Zip drive,
+ - for non-SCSI hardware whose drivers translate from and to SCSI
+   protocols, like the IDE-SCSI emulation driver and most notably
+   for all SATA drivers.
 
  To compile this driver as a module, choose M here and read
  .
  The module will be called scsi_mod.
 
  However, do not compile this as a module if your root file system
- (the one containing the directory /) is located on a SCSI device.
+ (the one containing the directory /) is located on a SCSI device
+ or on a device whose driver represents it as SCSI device, as
+ indicated above.  Choose Y in this case, or set up an initrd.
+
+ Subsequent options in this menu enable specific SCSI command set
+ support for harddisks, CD/DVD-ROM/R/W, tapes etc..  This menu also
+ presents options for specific SCSI controllers, while options for
+ some other SCSI transports and all non-SCSI controllers are located
+ in other menus (SATA, USB, FireWire etc.).
 
 config SCSI_DMA
bool
@@ -120,7 +128,7 @@ config BLK_DEV_SR
tristate "SCSI CDROM support"
depends on SCSI
---help---
- If you want to use a SCSI or FireWire CD-ROM under Linux,
+ If you want to use a SCSI, SATA, USB or FireWire CD-ROM or DVD-ROM,
  say Y and read the SCSI-HOWTO and the CDROM-HOWTO at
  . Also make sure to say
  Y or M to "ISO 9660 CD-ROM file system support" later.

-- 
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: sata & scsi suggestion for make menuconfig

2007-09-14 Thread Stefan Richter
Adrian Bunk wrote:
> On Fri, Sep 14, 2007 at 04:54:07PM +0200, Stefan Richter wrote:
>> The patch which is discussed here is specifically targeted towards users
>> who are convinced that they can migrate to different drivers without
>> reading Kconfig help texts.
> 
> Nothing about the patch is only about migration.
> 
> The same applies if you configure a kernel from scratch.
> 
> Do "make menuconfig" with the .config you are normally using, count the 
> number of options that are visible, and ask yourself whether we can 
> really expect users to read the help texts for every single option shown.
> 
> People mostly read help texts for options where they don't understand 
> what this option is about - and "Serial ATA" therefore is an option that 
> is likely to get enabled without the user looking at the help text.

If you create .config from scratch, then you can get away without
reading help texts if you have a target with minimal hardware and
protocols requirements and you know all the subsystems involved.

In all other cases, you theoretically need to read all help texts (minus
the ones that don't appear because you deselect entire subsystems).  In
practice, this takes too much time, hence you take an existing .config
(yours or somebody else's) and go from there.

Whenever one enables an option for the first time, it would IMO be
foolish to ignore its help text.
-- 
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: sata & scsi suggestion for make menuconfig

2007-09-14 Thread Adrian Bunk
On Fri, Sep 14, 2007 at 04:54:07PM +0200, Stefan Richter wrote:
> Adrian Bunk wrote:
> > On Sun, Sep 09, 2007 at 05:11:44PM -0400, Jeff Garzik wrote:
> >> Let's step back a moment and consider the actual scale and impact of the 
> >> problem at hand.
> >>
> >> The vast majority of users are consumers of pre-compiled kernels, built by 
> >> People With Clue(tm), who figured this stuff out as soon as it was 
> >> introduced.
> [...]
> > In my experience, the vast majority of kconfig users are not the few 
> > people working on distribution kernels, most of the kconfig userbase 
> > could be better described by the use case "sysadmin who knows about the 
> > hardware in his machine and which filesystems he uses".
> 
> The patch which is discussed here is specifically targeted towards users
> who are convinced that they can migrate to different drivers without
> reading Kconfig help texts.

Nothing about the patch is only about migration.

The same applies if you configure a kernel from scratch.

Do "make menuconfig" with the .config you are normally using, count the 
number of options that are visible, and ask yourself whether we can 
really expect users to read the help texts for every single option shown.

People mostly read help texts for options where they don't understand 
what this option is about - and "Serial ATA" therefore is an option that 
is likely to get enabled without the user looking at the help text.

> Stefan Richter

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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: sata & scsi suggestion for make menuconfig

2007-09-14 Thread Stefan Richter
Adrian Bunk wrote:
> On Sun, Sep 09, 2007 at 05:11:44PM -0400, Jeff Garzik wrote:
>> Let's step back a moment and consider the actual scale and impact of the 
>> problem at hand.
>>
>> The vast majority of users are consumers of pre-compiled kernels, built by 
>> People With Clue(tm), who figured this stuff out as soon as it was 
>> introduced.
[...]
> In my experience, the vast majority of kconfig users are not the few 
> people working on distribution kernels, most of the kconfig userbase 
> could be better described by the use case "sysadmin who knows about the 
> hardware in his machine and which filesystems he uses".

The patch which is discussed here is specifically targeted towards users
who are convinced that they can migrate to different drivers without
reading Kconfig help texts.
-- 
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 1/4] scsi: megaraid_sas -- add hibernation support

2007-09-14 Thread James Bottomley
On Tue, 2007-09-11 at 12:21 +, linux-box wrote:
> The megaraid_sas driver doesn't support the hibernation, the suspend/resume  
> routine implemented to support the hibernation.
> 
> Signed-off-by: Bo Yang <[EMAIL PROTECTED]> 

Just from a process point of view, your email from: is linux-box
<[EMAIL PROTECTED]>, but your signoff is Bo Yang <[EMAIL PROTECTED]>, I'm
assuming the signoff line is the real name you want me to use?

> @@ -2525,6 +2560,138 @@ static void megasas_shutdown_controller(
>  }
>  
>  /**
> + * megasas_suspend -driver suspend entry point
> + * @pdev:   PCI device structure
> + * @state:   PCI power state to suspend routine
> + */
> +static int __devinit
> +megasas_suspend(struct pci_dev *pdev, pm_message_t state)
> +{
> + struct Scsi_Host *host;
> + struct megasas_instance *instance;
> +
> + instance = pci_get_drvdata(pdev);
> + host = instance->host;
> +
> + megasas_flush_cache(instance);
> + megasas_shutdown_controller(instance, MR_DCMD_HIBERNATE_SHUTDOWN);
> + tasklet_kill(&instance->isr_tasklet);
> +
> + pci_set_drvdata(instance->pdev, instance);
> + instance->instancet->disable_intr(instance->reg_set);
> + free_irq(instance->pdev->irq, instance);
> +
> + scsi_host_put(host);

This can't be right.  You're not relinquishing the host here, since you
simply pick it out of the pci driver data on resume.

> +
> + pci_save_state(pdev);
> + pci_disable_device(pdev);
> +
> + pci_set_power_state(pdev, pci_choose_state(pdev, state));
> +
> + return 0;
> +}
> +
> +/**
> + * megasas_resume-  driver resume entry point
> + * @pdev:   PCI device structure
> + */
> +static int __devinit
> +megasas_resume(struct pci_dev *pdev)
> +{
> + int rval;
> + struct Scsi_Host *host;
> + struct megasas_instance *instance;
> +
> + instance = pci_get_drvdata(pdev);
> + host = instance->host;

As in here ... to get the correct refcounting, you'd have to bump up the
reference here.  However, I don't think the put on suspend is correct.

> +   pci_set_power_state(pdev, PCI_D0);
> +   pci_enable_wake(pdev, PCI_D0, 0);
> +   pci_restore_state(pdev);
> +
> +   /*
> +* PCI prepping: enable device set bus mastering and dma mask
> +*/
> +   rval = pci_enable_device(pdev);
> +
> +   if (rval) {
> +   printk(KERN_ERR "megasas: Enable device failed\n");
> +   return rval;
> +   }
> +
> +   pci_set_master(pdev);
> +
> +   if (megasas_set_dma_mask(pdev))
> +   goto fail_set_dma_mask;
> +
> +   /*
> +* Initialize MFI Firmware
> +*/
> +
> +   *instance->producer = 0;
> +   *instance->consumer = 0;
> +
> +   atomic_set(&instance->fw_outstanding, 0);
> +
> +   /*
> +* We expect the FW state to be READY
> +*/
> +   if (megasas_transition_to_ready(instance))
> +   goto fail_ready_state;
> +
> +   if (megasas_issue_init_mfi(instance))
> +   goto fail_init_mfi;
> +
> +   tasklet_init(&instance->isr_tasklet, megasas_complete_cmd_dpc,
> +   (unsigned long)instance);
> +
> +   /*
> +* Register IRQ
> +*/
> +   if (request_irq(pdev->irq, megasas_isr, IRQF_SHARED,
> +   "megasas", instance)) {
> +   printk(KERN_ERR "megasas: Failed to register IRQ\n");
> +   goto fail_irq;
> +   }
> +
> +   instance->instancet->enable_intr(instance->reg_set);
> +
> +   /*
> +* Store instance in PCI softstate
> +*/
> +   pci_set_drvdata(pdev, instance);

This better be redundant ... you picked the instance out of the driver
data at the beginning of this routine ... it better still be there or
else something is seriously wrong.

> +
> +   /*
> +* Initiate AEN (Asynchronous Event Notification)
> +*/
> +   if (megasas_start_aen(instance))
> +   printk(KERN_ERR "megasas: Start AEN failed\n");
> +
> +   return 0;


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: 2.6.23-rc4-mm1

2007-09-14 Thread Torsten Kaiser
On 9/14/07, Andy Whitcroft <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 11, 2007 at 04:31:12AM +0900, FUJITA Tomonori wrote:
> [...]
> >
> > Even if we revert the qla1280 patch, scsi-ml still sends chaining sg
> > list. So it doesn't work.
> >
> > The following patch disables chaining sg list for qla1280. If the fix
> > that I've just sent doesn't work, please try this.
>
> Ok, the other patch _did_ work, but this got tested anyhow and it did
> _not_ fix things.
>

Sorry to confirm this. My RAID5 got destroyed a second time.
To summarize what worked / not worked / and seems to work for me:

First 2 tries with unpatched rc4-mm1: Both times one sata_sil24-drive got kicked
Then I switched back to rc3-mm1, 18 boots with that kernel worked.
Then I tried the patched rc4-mm1 and it worked too.
The next boot also worked, but the third time kicked a drive out again.
But as nobody reads logs, I did not notice that and keep using the
patched rc4-mm1.
The next 5 times the system worked normally with the two remaining drives.
The sixth boot kicked the second sata_sil24 drive. That I did notice...
After reassembling the RAID, I'm now back to the patch rc4-mm1 that
did boot correctly this time.
So the patch just makes it unlikelier to hit the bug. Instead of
failing 2 out of 2 times, it only failed 2 out of 8 times.
I compared the rc4-mm1 boot from a working case and the case where it
kicked the first drive. Nothing seems to stand out...

< == good rc4-mm1 boot
> == bad rc4-mm1 boot that kicked the drive

145c145
< CPU 0: aperture @ 400 size 32 MB
---
> CPU 0: aperture @ b7f000 size 32 MB
154c154
< Calibrating delay using timer specific routine.. 5203.23 BogoMIPS
(lpj=26016160)
---
> Calibrating delay using timer specific routine.. 5203.22 BogoMIPS 
> (lpj=26016138)
169c169
< APIC timer calibration result 1248
---
> APIC timer calibration result 1244
173c173
< Calibrating delay using timer specific routine.. 5222.40 BogoMIPS
(lpj=26112010)
---
> Calibrating delay using timer specific routine.. 5200.01 BogoMIPS 
> (lpj=2652)
182c182
< Calibrating delay using timer specific routine.. 5222.73 BogoMIPS
(lpj=26113694)
---
> Calibrating delay using timer specific routine.. 5200.01 BogoMIPS 
> (lpj=2681)
191c191
< Calibrating delay using timer specific routine.. 5223.07 BogoMIPS
(lpj=26115369)
---
> Calibrating delay using timer specific routine.. 5200.03 BogoMIPS 
> (lpj=26000164)
269d268
< Switched to high resolution mode on CPU 3
270a270
> Switched to high resolution mode on CPU 3
502,509c502,509
< raid6: int64x1   2634 MB/s
< raid6: int64x2   3244 MB/s
< raid6: int64x4   3405 MB/s
< raid6: int64x8   2614 MB/s
< raid6: sse2x13607 MB/s
< raid6: sse2x24834 MB/s
< raid6: sse2x44946 MB/s
< raid6: using algorithm sse2x4 (4946 MB/s)
---
> raid6: int64x1   2680 MB/s
> raid6: int64x2   3232 MB/s
> raid6: int64x4   3411 MB/s
> raid6: int64x8   2620 MB/s
> raid6: sse2x13606 MB/s
> raid6: sse2x24810 MB/s
> raid6: sse2x44910 MB/s
> raid6: using algorithm sse2x4 (4910 MB/s)
567c567
< md1: bitmap initialized from disk: read 10/10 pages, set 96 bits
---
> md1: bitmap initialized from disk: read 10/10 pages, set 104 bits
568a569,655
> ata1.00: exception Emask 0x20 SAct 0x1 SErr 0x0 action 0x2
> ata1.00: irq_stat 0x00020002, PCI master abort while fetching SGT
> ata1.00: cmd 61/08:00:09:d6:42/00:00:25:00:00/40 tag 0 cdb 0x0 data 4096 out
>  res 50/00:00:af:ea:42/00:00:25:00:00/e0 Emask 0x20 (host bus error)
> ata1.00: status: {DRDY }
> ata1: soft resetting link
> ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> ata1.00: configured for UDMA/100
> ata1: EH complete
> sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors (320073 MB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support 
> DPO or FUA
> ata1.00: exception Emask 0x20 SAct 0x1 SErr 0x0 action 0x2
> ata1.00: irq_stat 0x00020002, PCI master abort while fetching SGT
> ata1.00: cmd 61/08:00:09:d6:42/00:00:25:00:00/40 tag 0 cdb 0x0 data 4096 out
>  res 50/00:00:af:ea:42/00:00:25:00:00/e0 Emask 0x20 (host bus error)
> ata1.00: status: {DRDY }
> ata1: soft resetting link
> ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> ata1.00: configured for UDMA/100
> ata1: EH complete
> sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors (320073 MB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support 
> DPO or FUA
> ata1.00: exception Emask 0x20 SAct 0x1 SErr 0x0 action 0x2
> ata1.00: irq_stat 0x00020002, PCI master abort while fetching SGT
> ata1.00: cmd 61/08:00:09:d6:42/00:00:25:00:00/40 tag 0 cdb 0x0 data 4096 out
>  res 50/00:00:af:ea:42/00:00:25:00:00/e0 Emask 0x20 (host bus error)
> ata1.00: status: {DRDY }
> ata1: soft resetting link
> ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

Re: [PATCH 3/4] scsi: megaraid_sas - add module param max_sectors, cmd_per_lun

2007-09-14 Thread Christoph Hellwig
On Fri, Sep 14, 2007 at 03:32:16AM -0700, Andrew Morton wrote:
> y'know, if some brave soul were to write

y'know - some brave sould already did it.

> static inline void *scsi_host_data(struct Scsi_Host *host)
> {
>   return (void *)host->hostdata;
> }
> 
> we could remove about 1000 ugly casts from scsi.

it's called shost_priv, but I couldn't get a whole lot of driver
authors to switch over yet.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/4] scsi: megaraid_sas - add module param max_sectors, cmd_per_lun

2007-09-14 Thread Andrew Morton
On Tue, 11 Sep 2007 08:34:33 -0400 linux-box <[EMAIL PROTECTED]> wrote:

> + struct megasas_instance *instance =
> + (struct megasas_instance *)host->hostdata;

y'know, if some brave soul were to write

static inline void *scsi_host_data(struct Scsi_Host *host)
{
return (void *)host->hostdata;
}

we could remove about 1000 ugly casts from scsi.

Just a thought...

-
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] scsi: megaraid_sas -- add module param fast_load

2007-09-14 Thread Andrew Morton
On Tue, 11 Sep 2007 08:28:14 -0400 linux-box <[EMAIL PROTECTED]> wrote:

> Driver will skip physical devices scan for the first time if the fast_load is 
> set

When preparing changelogs it is often good to describe _why_ the change is
being made, as well as what the change does.

It may be obvious to some people why users of this driver might want to use
this feature, but I don't have clue why you did this.

-
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/4] scsi: megaraid_sas -- add hibernation support

2007-09-14 Thread Andrew Morton
On Tue, 11 Sep 2007 12:21:24 + linux-box <[EMAIL PROTECTED]> wrote:

> The megaraid_sas driver doesn't support the hibernation, the suspend/resume  
> routine implemented to support the hibernation.
> 
> Signed-off-by: Bo Yang <[EMAIL PROTECTED]> 
> 
> ---
>  drivers/scsi/megaraid/megaraid_sas.c |  309 +++--
>  drivers/scsi/megaraid/megaraid_sas.h |1
>  2 files changed, 240 insertions(+), 70 deletions(-)
> diff -rupN linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c 
> linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.c
> --- linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c2007-07-01 
> 22:25:57.0 -0400
> +++ linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.c 2007-07-31 
> 23:57:11.0 -0400
> @@ -1804,6 +1804,81 @@ static void megasas_complete_cmd_dpc(uns
>  }
>  
>  /**
> + * megasas_issue_init_mfi -  Initializes the FW
> + * @instance:Adapter soft state
> + *
> + * Issues the INIT MFI cmd
> + */
> +static int
> +megasas_issue_init_mfi(struct megasas_instance *instance)
> +{
> + u32 context;
> +
> + struct megasas_cmd *cmd;
> +
> + struct megasas_init_frame *init_frame;
> + struct megasas_init_queue_info *initq_info;
> + dma_addr_t init_frame_h;
> + dma_addr_t initq_info_h;
> +
> + /*
> +  * Prepare a init frame. Note the init frame points to queue info
> +  * structure. Each frame has SGL allocated after first 64 bytes. For
> +  * this frame - since we don't need any SGL - we use SGL's space as
> +  * queue info structure
> +  *
> +  * We will not get a NULL command below. We just created the pool.
> +  */
> + cmd = megasas_get_cmd(instance);
> +
> + init_frame = (struct megasas_init_frame *)cmd->frame;

This would be better as

init_frame = &cmd->frame.init;

please review the whole driver for this.

> + initq_info = (struct megasas_init_queue_info *)
> + ((unsigned long)init_frame + 64);

And here we could do

initq_info = (struct megasas_init_queue_info *)(init_frame + 1);

although that's not really a lot nicer.


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: 2.6.23-rc4-mm1

2007-09-14 Thread Andy Whitcroft
On Tue, Sep 11, 2007 at 04:31:12AM +0900, FUJITA Tomonori wrote:
[...]
> > The only patch which touches qla1280 is git-block.patch.  From a quick
> > squizz the change looks OK, although it's tricky and something might have
> > broken.
> > 
> > (the dprintk at line 2929 needs to print remseg, not seg_cnt).
> > 
> > Can you retest with that change reverted (below)?  If it's not that then
> > perhaps something in scsi core broke, dunno.
> 
> Even if we revert the qla1280 patch, scsi-ml still sends chaining sg
> list. So it doesn't work.
> 
> The following patch disables chaining sg list for qla1280. If the fix
> that I've just sent doesn't work, please try this.

Ok, the other patch _did_ work, but this got tested anyhow and it did
_not_ fix things.

> -
> From: FUJITA Tomonori <[EMAIL PROTECTED]>
> Subject: [PATCH] add use_sg_chaining option to scsi_host_template
> 
> This option is true if a low-level driver can support sg
> chaining. This will be removed eventually when all the drivers are
> converted to support sg chaining. q->max_phys_segments is set to
> SCSI_MAX_SG_SEGMENTS if false.
> 
> Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
> ---
>  arch/ia64/hp/sim/simscsi.c|1 +
>  drivers/scsi/3w-9xxx.c|1 +
>  drivers/scsi/3w-.c|1 +
>  drivers/scsi/BusLogic.c   |1 +
>  drivers/scsi/NCR53c406a.c |3 ++-
>  drivers/scsi/a100u2w.c|1 +
>  drivers/scsi/aacraid/linit.c  |1 +
>  drivers/scsi/aha1740.c|1 +
>  drivers/scsi/aic7xxx/aic79xx_osm.c|1 +
>  drivers/scsi/aic7xxx/aic7xxx_osm.c|1 +
>  drivers/scsi/aic7xxx_old.c|1 +
>  drivers/scsi/arcmsr/arcmsr_hba.c  |1 +
>  drivers/scsi/dc395x.c |1 +
>  drivers/scsi/dpt_i2o.c|1 +
>  drivers/scsi/eata.c   |3 ++-
>  drivers/scsi/hosts.c  |1 +
>  drivers/scsi/hptiop.c |1 +
>  drivers/scsi/ibmmca.c |1 +
>  drivers/scsi/ibmvscsi/ibmvscsi.c  |1 +
>  drivers/scsi/initio.c |1 +
>  drivers/scsi/ipr.c|1 +
>  drivers/scsi/lpfc/lpfc_scsi.c |2 ++
>  drivers/scsi/mac53c94.c   |1 +
>  drivers/scsi/megaraid.c   |1 +
>  drivers/scsi/megaraid/megaraid_mbox.c |1 +
>  drivers/scsi/megaraid/megaraid_sas.c  |1 +
>  drivers/scsi/mesh.c   |1 +
>  drivers/scsi/nsp32.c  |1 +
>  drivers/scsi/pcmcia/sym53c500_cs.c|1 +
>  drivers/scsi/qla2xxx/qla_os.c |2 ++
>  drivers/scsi/qla4xxx/ql4_os.c |1 +
>  drivers/scsi/qlogicfas.c  |1 +
>  drivers/scsi/scsi_lib.c   |5 -
>  drivers/scsi/stex.c   |1 +
>  drivers/scsi/sym53c416.c  |1 +
>  drivers/scsi/sym53c8xx_2/sym_glue.c   |1 +
>  drivers/scsi/u14-34f.c|1 +
>  drivers/scsi/ultrastor.c  |1 +
>  drivers/scsi/wd7000.c |1 +
>  include/scsi/scsi_host.h  |   13 +
>  40 files changed, 59 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/ia64/hp/sim/simscsi.c b/arch/ia64/hp/sim/simscsi.c
> index 4552a1c..e711657 100644
> --- a/arch/ia64/hp/sim/simscsi.c
> +++ b/arch/ia64/hp/sim/simscsi.c
> @@ -360,6 +360,7 @@ static struct scsi_host_template driver_template = {
>   .max_sectors= 1024,
>   .cmd_per_lun= SIMSCSI_REQ_QUEUE_LEN,
>   .use_clustering = DISABLE_CLUSTERING,
> + .use_sg_chaining= ENABLE_SG_CHAINING,
>  };
>  
>  static int __init
> diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
> index efd9d8d..fb14014 100644
> --- a/drivers/scsi/3w-9xxx.c
> +++ b/drivers/scsi/3w-9xxx.c
> @@ -1990,6 +1990,7 @@ static struct scsi_host_template driver_template = {
>   .max_sectors= TW_MAX_SECTORS,
>   .cmd_per_lun= TW_MAX_CMDS_PER_LUN,
>   .use_clustering = ENABLE_CLUSTERING,
> + .use_sg_chaining= ENABLE_SG_CHAINING,
>   .shost_attrs= twa_host_attrs,
>   .emulated   = 1
>  };
> diff --git a/drivers/scsi/3w-.c b/drivers/scsi/3w-.c
> index c7995fc..a64153b 100644
> --- a/drivers/scsi/3w-.c
> +++ b/drivers/scsi/3w-.c
> @@ -2261,6 +2261,7 @@ static struct scsi_host_template driver_template = {
>   .max_sectors= TW_MAX_SECTORS,
>   .cmd_per_lun= TW_MAX_CMDS_PER_LUN,  
>   .use_clustering = ENABLE_CLUSTERING,
> + .use_sg_chaining= ENABLE_SG_CHAINING,
>   .shost_attrs= tw_host_attrs,
>   .emulated   = 1
>  };
> diff --git a/drivers/scsi/BusLogic.c b/drivers/scsi/BusLogic.c
> index 9b20617..49e1ffa 100644
> --- a/drivers/scsi/BusLogic.c
> +++ b/drivers/scsi/BusLogic.c
> @@ -3575,6 +3575,7 @@ static

Re: [PATCH] Fix race with shared tag queue maps

2007-09-14 Thread Jens Axboe
On Thu, Sep 13 2007, Linus Torvalds wrote:
> 
> 
> On Thu, 13 Sep 2007, Jens Axboe wrote:
> > 
> > My bad, I think I added the smp_mb__before_clear_bit() when it was
> > __test_and_set_bit() like in the first hunk.
> 
> Ahh, that wouldn't work at all. The "__test_and_set_bit()" thing isn't 
> atomic at all, and no amount of memory barriers around it would help 
> (you'd need to use real locking, but at that point the memory barriers are 
> pointless anyway).

Hence the change, it looks like an oversight from when we didn't allow
sharing of tag maps (then the queue lock provided adequate protection).

> > +   /*
> > +* Ensure ordering between ->tag_index[tag] clear and tag clear
> > +*/
> > +   smp_mb__after_clear_bit();
> 
> You still left this one. But never mind - I already edited your original 
> patch and it's in my tree with both of those things removed.

I took at look at the committed patch and it looks fine, thanks Linus.

-- 
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