[PATCH 0/5] mpt fusion: Add logging support

[PATCH 0/5] mpt fusion: Add logging support

[Prakash, Sathya]

The patches in this patch set adds support for logging facility that can be used
to debug a number of Fusion MPT related problems.

The logging support can be enabled or disabled changing the kernel
configuration flag CONFIF_FUSION_LOGGING

The debug level can be programmed on the fly via SysFS (hex values)
	echo [level] > /sys/class/scsi_host/host#/debug_level
and also can be passed as module parameter mpt_debug_level for mptbase.ko

There are various debug levels that can be found in the source file mptdebug.h

Since the difference is of size 175 KB, it is split into five different patches
grouped based on the files as described below.

	[PATCH 1/5] : Changes for logging support in Kconfig, Makefile,
			 mptbase.h and addition of mptdebug.h
 	[PATCH 2/5] : Changes in mptbase.c for logging support
 	[PATCH 3/5] : Changes in mptscsih.c for logging support
 	[PATCH 4/5] : Changes in mptfc.c mptlan.c mptsas.c and mptspi.c
		      for logging support
 	[PATCH 5/5] : Changes in mptctl.c for logging support

signed-off-by: Sathya Prakash <sathya.prakash@lsi.com>
---

RE: [PATCH 0/5] mpt fusion: Add logging support

[Moore, Eric]

On Tuesday, July 24, 2007 4:07 AM,  Prakash, Sathya wrote:

> The patches in this patch set adds support for logging 
> facility that can be used
> to debug a number of Fusion MPT related problems.
> 
> The logging support can be enabled or disabled changing the kernel
> configuration flag CONFIF_FUSION_LOGGING
> 
> The debug level can be programmed on the fly via SysFS (hex values)
> 	echo [level] > /sys/class/scsi_host/host#/debug_level
> and also can be passed as module parameter mpt_debug_level 
> for mptbase.ko
> 
> There are various debug levels that can be found in the 
> source file mptdebug.h
> 
> Since the difference is of size 175 KB, it is split into five 
> different patches
> grouped based on the files as described below.
> 
> 	[PATCH 1/5] : Changes for logging support in Kconfig, Makefile,
> 			 mptbase.h and addition of mptdebug.h
>  	[PATCH 2/5] : Changes in mptbase.c for logging support
>  	[PATCH 3/5] : Changes in mptscsih.c for logging support
>  	[PATCH 4/5] : Changes in mptfc.c mptlan.c mptsas.c and mptspi.c
> 		      for logging support
>  	[PATCH 5/5] : Changes in mptctl.c for logging support
> 


These set of patchs are to replace the current cumbersome implementation
of enabling debug defines in the driver Makefile, and recompiling the
driver.    The new method allows the enduser to enable/disable debug
information any time without having to recompile or reboot the system.
These code has been verified in the LSI test labs for several months,
and there is no performance regressions with this.  If there are no
other further objections, please apply.

ACK

Eric Moore     

Re: [PATCH 0/5] mpt fusion: Add logging support

[James Bottomley]

On Tue, 2007-07-24 at 15:36 +0530, Prakash, Sathya wrote:
> The patches in this patch set adds support for logging facility that can be used
> to debug a number of Fusion MPT related problems.
> 
> The logging support can be enabled or disabled changing the kernel
> configuration flag CONFIF_FUSION_LOGGING
> 
> The debug level can be programmed on the fly via SysFS (hex values)
> 	echo [level] > /sys/class/scsi_host/host#/debug_level
> and also can be passed as module parameter mpt_debug_level for mptbase.ko

The way your module parameter works is slightly counter intuitive.  On
all our other drivers, you can write a value into 

/sys/module/<module>/parameters/<debug parameter>

And have it acted on immediately.  In yours, it seems only to work
before the host is probed (because after that, the value in the ioc
structure is what's used).

The other question is are you really sure you actually want per host
debugging?  is the added flexibility in being able to turn it on and off
per host worth the problems of explaining to the users where to find the
parameter?  I've got to bet that 95% of the installations only have a
single fusion card anyway.  would it not be simpler just to have a
global module parameter that can be set and acted on from /sys/modules?

James

RE: [PATCH 0/5] mpt fusion: Add logging support

[Moore, Eric]

On Friday, July 27, 2007 10:21 AM, wrote: 
> 
> The way your module parameter works is slightly counter intuitive.  On
> all our other drivers, you can write a value into 
> 
> /sys/module/<module>/parameters/<debug parameter>
> 
> And have it acted on immediately.  In yours, it seems only to work
> before the host is probed (because after that, the value in the ioc
> structure is what's used).

not true,  the debug parameter can be configured prior to the host being
probed.    We have a command line option called mpt_debug_level, that
can set the debug level from mptbase.ko.  That way you can enable
certain debug during probe time prior to the loading of
mptsas/mptfc/mptspi. Once those upper drivers are loaded, you can toggle
off and on the debug via the shost_attrib. This is explained in
mptdebug.h.

> 
> The other question is are you really sure you actually want per host
> debugging?  is the added flexibility in being able to turn it 
> on and off
> per host worth the problems of explaining to the users where 
> to find the
> parameter?  I've got to bet that 95% of the installations only have a
> single fusion card anyway.  would it not be simpler just to have a
> global module parameter that can be set and acted on from 
> /sys/modules?
> 

I like having the added flexibility, and potential customers may agree.
Our driver stack support multiple bus protocols, unlike other vendors,
and some customers may ship fibre, sas, and spi in a single systems..
For my personal use, I like being able to have per host debugging, as I
have multiple cards in my systems.    There are several cases I've
debugged two controller case, when boot OS is on one controller, and the
debug efforts on another, in that case I only want to concern myself
with the debug in question, not boot OS.  The method of debug usesage is
in mptdebug.h, so I would think people would look there, and figure it
out.  I also have a script below that sets all the host debug sas chips.
Does this sound reasonable? If not, let me know.


---[Cut below]---
#!/bin/bash
#set -x
if (( $# != 1 )); then
	echo -e \\n"useage: set_debug_level <level>"
	echo -e \\n
	exit 1
fi

scsi_host="/sys/class/scsi_host"
cd ${scsi_host}
subfolders=`ls -1`
for i in ${subfolders};  do
	cd ${i}
	if [ `cat proc_name` != "mptsas" ]; then
		cd ${scsi_host}
		continue;
	fi;
	echo $1 > debug_level
	debug_level=`cat debug_level`
	echo for ${i} debug_level=$debug_level
	cd ${scsi_host}
done;
---[Cut above]---

RE: [PATCH 0/5] mpt fusion: Add logging support

[James Bottomley]

On Fri, 2007-07-27 at 16:16 -0600, Moore, Eric wrote:
> On Friday, July 27, 2007 10:21 AM, wrote: 
> > 
> > The way your module parameter works is slightly counter intuitive.  On
> > all our other drivers, you can write a value into 
> > 
> > /sys/module/<module>/parameters/<debug parameter>
> > 
> > And have it acted on immediately.  In yours, it seems only to work
> > before the host is probed (because after that, the value in the ioc
> > structure is what's used).
> 
> not true,  the debug parameter can be configured prior to the host being
> probed.

That's what I just said ... if you mean can be configured *after* the
host being probed, then I think the parameter needs a
module_param_call() so you can intercept the set and update the ioc
structures accordingly.

>     We have a command line option called mpt_debug_level, that
> can set the debug level from mptbase.ko.  That way you can enable
> certain debug during probe time prior to the loading of
> mptsas/mptfc/mptspi. Once those upper drivers are loaded, you can toggle
> off and on the debug via the shost_attrib. This is explained in
> mptdebug.h.

Yes, but my point was that most other module parameters are settable
from /sys as well ... this one has some strange rules.

> > 
> > The other question is are you really sure you actually want per host
> > debugging?  is the added flexibility in being able to turn it 
> > on and off
> > per host worth the problems of explaining to the users where 
> > to find the
> > parameter?  I've got to bet that 95% of the installations only have a
> > single fusion card anyway.  would it not be simpler just to have a
> > global module parameter that can be set and acted on from 
> > /sys/modules?
> > 
> 
> I like having the added flexibility, and potential customers may agree.
> Our driver stack support multiple bus protocols, unlike other vendors,
> and some customers may ship fibre, sas, and spi in a single systems..
> For my personal use, I like being able to have per host debugging, as I
> have multiple cards in my systems.    There are several cases I've
> debugged two controller case, when boot OS is on one controller, and the
> debug efforts on another, in that case I only want to concern myself
> with the debug in question, not boot OS.  The method of debug usesage is
> in mptdebug.h, so I would think people would look there, and figure it
> out.  I also have a script below that sets all the host debug sas chips.
> Does this sound reasonable? If not, let me know.

OK fair enough ... I'm just pointing out it's non standard.

I really think the module parameter has to be hooked to act as a global
setting, but otherwise, this looks fine.

James

RE: [PATCH 0/5] mpt fusion: Add logging support

[James Bottomley]

On Fri, 2007-07-27 at 18:30 -0400, James Bottomley wrote:
> On Fri, 2007-07-27 at 16:16 -0600, Moore, Eric wrote:
> > On Friday, July 27, 2007 10:21 AM, wrote: 
> > > 
> > > The way your module parameter works is slightly counter intuitive.  On
> > > all our other drivers, you can write a value into 
> > > 
> > > /sys/module/<module>/parameters/<debug parameter>
> > > 
> > > And have it acted on immediately.  In yours, it seems only to work
> > > before the host is probed (because after that, the value in the ioc
> > > structure is what's used).
> > 
> > not true,  the debug parameter can be configured prior to the host being
> > probed.
> 
> That's what I just said ... if you mean can be configured *after* the
> host being probed, then I think the parameter needs a
> module_param_call() so you can intercept the set and update the ioc
> structures accordingly.

I tell you what, let me just show you the actual patch.  This allows you
to write to the /sys/module/mptbase/parameters/mpt_debug_level and have
it take effect in every ioc.

James

diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index e866dac..414c109 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -88,7 +88,9 @@ module_param(mpt_channel_mapping, int, 0);
 MODULE_PARM_DESC(mpt_channel_mapping, " Mapping id's to channels (default=0)");
 
 static int mpt_debug_level;
-module_param(mpt_debug_level, int, 0);
+static int mpt_set_debug_level(const char *val, struct kernel_param *kp);
+module_param_call(mpt_debug_level, mpt_set_debug_level, param_get_int,
+		  &mpt_debug_level, 0600);
 MODULE_PARM_DESC(mpt_debug_level, " debug level - refer to mptdebug.h - (default=0)");
 
 #ifdef MFCNT
@@ -220,6 +222,19 @@ pci_enable_io_access(struct pci_dev *pdev)
 	pci_write_config_word(pdev, PCI_COMMAND, command_reg);
 }
 
+static int mpt_set_debug_level(const char *val, struct kernel_param *kp)
+{
+	int ret = param_set_int(val, kp);
+	MPT_ADAPTER *ioc;
+
+	if (ret)
+		return ret;
+
+	list_for_each_entry(ioc, &ioc_list, list)
+		ioc->debug_level = mpt_debug_level;
+	return 0;
+}
+
 /*
  *  Process turbo (context) reply...
  */

RE: [PATCH 0/5] mpt fusion: Add logging support

[Moore, Eric]

On Saturday, July 28, 2007 11:40 AM,  James Bottomley wrote: 
> 
> I tell you what, let me just show you the actual patch.  This 
> allows you
> to write to the 
> /sys/module/mptbase/parameters/mpt_debug_level and have
> it take effect in every ioc.
> 

ACK,  If possible, I would like this patch thrown in with the other
fusion logging patchs you added over the weekend to the
scsi-rc-fixes-2.6 stream. Thanks.

On another note, while unloading the driver, and I get an following opps
from bsg in the context of scsi_remove_host.   This is w/o the "SMP
passthrough" patch, so why would fusion drivers be linked to bsg?
Woudn't this break mptspi and mptfc, since they will not be working with
bsg.


Call Trace:
 [<ffffffff881f519c>] :scsi_transport_sas:sas_bsg_remove+0x27/0x32
 [<ffffffff881f6349>] :scsi_transport_sas:sas_host_remove+0x30/0x34
 [<ffffffff80375326>] transport_remove_classdev+0x1d/0x4c
 [<ffffffff80375001>] attribute_container_device_trigger+0x69/0xa7
 [<ffffffff8803778b>] :scsi_mod:scsi_remove_host+0xcd/0xfa
 [<ffffffff883461ac>] :mptscsih:mptscsih_remove+0x32/0xae
 [<ffffffff8031416d>] pci_device_remove+0x24/0x48
 [<ffffffff803720ed>] __device_release_driver+0x91/0xb3
 [<ffffffff80372631>] driver_detach+0xd6/0x115
 [<ffffffff80371ba3>] bus_remove_driver+0x6d/0x90
 [<ffffffff803143f4>] pci_unregister_driver+0x17/0x6b
 [<ffffffff88355044>] :mptsas:mptsas_exit+0x10/0x5f
 [<ffffffff80252afb>] sys_delete_module+0x1b1/0x1e0
 [<ffffffff80307d9c>] __up_write+0x21/0x10d
 [<ffffffff8020bc4e>] system_call+0x7e/0x83

RE: [PATCH 0/5] mpt fusion: Add logging support

[FUJITA Tomonori]

From: "Moore, Eric" <Eric.Moore@lsi.com>
Subject: RE: [PATCH 0/5] mpt fusion: Add logging support
Date: Mon, 30 Jul 2007 12:33:00 -0600

> On Saturday, July 28, 2007 11:40 AM,  James Bottomley wrote: 
> > 
> > I tell you what, let me just show you the actual patch.  This 
> > allows you
> > to write to the 
> > /sys/module/mptbase/parameters/mpt_debug_level and have
> > it take effect in every ioc.
> > 
> 
> ACK,  If possible, I would like this patch thrown in with the other
> fusion logging patchs you added over the weekend to the
> scsi-rc-fixes-2.6 stream. Thanks.
> 
> On another note, while unloading the driver, and I get an following opps
> from bsg in the context of scsi_remove_host.   This is w/o the "SMP
> passthrough" patch, so why would fusion drivers be linked to bsg?
> Woudn't this break mptspi and mptfc, since they will not be working with
> bsg.
> 
> 
> Call Trace:
>  [<ffffffff881f519c>] :scsi_transport_sas:sas_bsg_remove+0x27/0x32
>  [<ffffffff881f6349>] :scsi_transport_sas:sas_host_remove+0x30/0x34
>  [<ffffffff80375326>] transport_remove_classdev+0x1d/0x4c
>  [<ffffffff80375001>] attribute_container_device_trigger+0x69/0xa7
>  [<ffffffff8803778b>] :scsi_mod:scsi_remove_host+0xcd/0xfa
>  [<ffffffff883461ac>] :mptscsih:mptscsih_remove+0x32/0xae
>  [<ffffffff8031416d>] pci_device_remove+0x24/0x48
>  [<ffffffff803720ed>] __device_release_driver+0x91/0xb3
>  [<ffffffff80372631>] driver_detach+0xd6/0x115
>  [<ffffffff80371ba3>] bus_remove_driver+0x6d/0x90
>  [<ffffffff803143f4>] pci_unregister_driver+0x17/0x6b
>  [<ffffffff88355044>] :mptsas:mptsas_exit+0x10/0x5f
>  [<ffffffff80252afb>] sys_delete_module+0x1b1/0x1e0
>  [<ffffffff80307d9c>] __up_write+0x21/0x10d
>  [<ffffffff8020bc4e>] system_call+0x7e/0x83

This patch fix the problem?

---
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Subject: [PATCH] scsi_transport_sas: initialize sas_host_attrs->q

fix the bug to call bsg_unregister_queue for an uninitialized queue.

Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
---
 drivers/scsi/scsi_transport_sas.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/scsi/scsi_transport_sas.c b/drivers/scsi/scsi_transport_sas.c
index 3120f4b..b0a21a2 100644
--- a/drivers/scsi/scsi_transport_sas.c
+++ b/drivers/scsi/scsi_transport_sas.c
@@ -270,6 +270,7 @@ static int sas_host_setup(struct transport_container *tc, struct device *dev,
 	sas_host->next_target_id = 0;
 	sas_host->next_expander_id = 0;
 	sas_host->next_port_id = 0;
+	sas_host->q = NULL;
 
 	if (sas_bsg_initialize(shost, NULL))
 		dev_printk(KERN_ERR, dev, "fail to a bsg device %d\n",
-- 
1.5.2.4

RE: [PATCH 0/5] mpt fusion: Add logging support

[Moore, Eric]

On Monday, July 30, 2007 4:32 PM,  FUJITA Tomonori wrote:
> > On another note, while unloading the driver, and I get an 
> following opps
> > from bsg in the context of scsi_remove_host.   This is w/o the "SMP
> > passthrough" patch, so why would fusion drivers be linked to bsg?
> > Woudn't this break mptspi and mptfc, since they will not be 
> working with
> > bsg.
> > 
> > 
> > Call Trace:
> >  [<ffffffff881f519c>] :scsi_transport_sas:sas_bsg_remove+0x27/0x32
> >  [<ffffffff881f6349>] :scsi_transport_sas:sas_host_remove+0x30/0x34
> >  [<ffffffff80375326>] transport_remove_classdev+0x1d/0x4c
> >  [<ffffffff80375001>] attribute_container_device_trigger+0x69/0xa7
> >  [<ffffffff8803778b>] :scsi_mod:scsi_remove_host+0xcd/0xfa
> >  [<ffffffff883461ac>] :mptscsih:mptscsih_remove+0x32/0xae
> >  [<ffffffff8031416d>] pci_device_remove+0x24/0x48
> >  [<ffffffff803720ed>] __device_release_driver+0x91/0xb3
> >  [<ffffffff80372631>] driver_detach+0xd6/0x115
> >  [<ffffffff80371ba3>] bus_remove_driver+0x6d/0x90
> >  [<ffffffff803143f4>] pci_unregister_driver+0x17/0x6b
> >  [<ffffffff88355044>] :mptsas:mptsas_exit+0x10/0x5f
> >  [<ffffffff80252afb>] sys_delete_module+0x1b1/0x1e0
> >  [<ffffffff80307d9c>] __up_write+0x21/0x10d
> >  [<ffffffff8020bc4e>] system_call+0x7e/0x83
> 
> This patch fix the problem?
> 
> ---
> From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> Subject: [PATCH] scsi_transport_sas: initialize sas_host_attrs->q
> 
> fix the bug to call bsg_unregister_queue for an uninitialized queue.
> 
> Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>

yes it does fix it.

I'm not sure if this has already been posted to lsml@, but please apply
to scsi-rc-fixes-2.6.

Thanks,
Eric

RE: [PATCH 0/5] mpt fusion: Add logging support

[FUJITA Tomonori]

On Tue, 31 Jul 2007 12:40:41 -0600
"Moore, Eric" <Eric.Moore@lsi.com> wrote:

> On Monday, July 30, 2007 4:32 PM,  FUJITA Tomonori wrote:
> > > On another note, while unloading the driver, and I get an 
> > following opps
> > > from bsg in the context of scsi_remove_host.   This is w/o the "SMP
> > > passthrough" patch, so why would fusion drivers be linked to bsg?
> > > Woudn't this break mptspi and mptfc, since they will not be 
> > working with
> > > bsg.
> > > 
> > > 
> > > Call Trace:
> > >  [<ffffffff881f519c>] :scsi_transport_sas:sas_bsg_remove+0x27/0x32
> > >  [<ffffffff881f6349>] :scsi_transport_sas:sas_host_remove+0x30/0x34
> > >  [<ffffffff80375326>] transport_remove_classdev+0x1d/0x4c
> > >  [<ffffffff80375001>] attribute_container_device_trigger+0x69/0xa7
> > >  [<ffffffff8803778b>] :scsi_mod:scsi_remove_host+0xcd/0xfa
> > >  [<ffffffff883461ac>] :mptscsih:mptscsih_remove+0x32/0xae
> > >  [<ffffffff8031416d>] pci_device_remove+0x24/0x48
> > >  [<ffffffff803720ed>] __device_release_driver+0x91/0xb3
> > >  [<ffffffff80372631>] driver_detach+0xd6/0x115
> > >  [<ffffffff80371ba3>] bus_remove_driver+0x6d/0x90
> > >  [<ffffffff803143f4>] pci_unregister_driver+0x17/0x6b
> > >  [<ffffffff88355044>] :mptsas:mptsas_exit+0x10/0x5f
> > >  [<ffffffff80252afb>] sys_delete_module+0x1b1/0x1e0
> > >  [<ffffffff80307d9c>] __up_write+0x21/0x10d
> > >  [<ffffffff8020bc4e>] system_call+0x7e/0x83
> > 
> > This patch fix the problem?
> > 
> > ---
> > From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> > Subject: [PATCH] scsi_transport_sas: initialize sas_host_attrs->q
> > 
> > fix the bug to call bsg_unregister_queue for an uninitialized queue.
> > 
> > Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> 
> yes it does fix it.
> 
> I'm not sure if this has already been posted to lsml@, but please apply
> to scsi-rc-fixes-2.6.

The following patch should fix this problem:

http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-rc-fixes-2.6.git;a=commit;h=c000c43cf12090972fad0fbb621d78c2100d0373

RE: [PATCH 0/5] mpt fusion: Add logging support

[Mr. James W. Laferriere]

 	Hello Eric ,

On Fri, 27 Jul 2007, Moore, Eric wrote:
> On Friday, July 27, 2007 10:21 AM, wrote:
>> The way your module parameter works is slightly counter intuitive.  On
>> all our other drivers, you can write a value into
>>
>> /sys/module/<module>/parameters/<debug parameter>
>>
>> And have it acted on immediately.  In yours, it seems only to work
>> before the host is probed (because after that, the value in the ioc
>> structure is what's used).
>
> not true,  the debug parameter can be configured prior to the host being
> probed.    We have a command line option called mpt_debug_level, that
> can set the debug level from mptbase.ko.  That way you can enable
> certain debug during probe time prior to the loading of
> mptsas/mptfc/mptspi. Once those upper drivers are loaded, you can toggle
> off and on the debug via the shost_attrib. This is explained in
> mptdebug.h.
 	Where's the mptdebug.h file in linux-2.6.22.1 ? (*)
(*)
  root@filesrv1:/usr/src # find  linux-2.6.22.1/drivers/message/ -name mptdebug.h -print
  root@filesrv1:/usr/src #

 	I take it that that file is only available thru a git repo at this 
time ?  I know it's in the sources you shared with me , but ...
 	Another thing where is shost_attrib defined ?  It's not even in the 
sources you shared with me .

 	Isn't *.h files an odd place to put debug information for a sys admin 
to find so s/he can find out howto debug their problem with a LSI device ?
 	Mind you that's just my opinion .  But It sure would be nice to have 
some relativlty decent document(s) available to this purpose in Documentation .

>> The other question is are you really sure you actually want per host
>> debugging?  is the added flexibility in being able to turn it
>> on and off
>> per host worth the problems of explaining to the users where
>> to find the
>> parameter?  I've got to bet that 95% of the installations only have a
>> single fusion card anyway.  would it not be simpler just to have a
>> global module parameter that can be set and acted on from
>> /sys/modules?
>
> I like having the added flexibility, and potential customers may agree.
> Our driver stack support multiple bus protocols, unlike other vendors,
> and some customers may ship fibre, sas, and spi in a single systems..
> For my personal use, I like being able to have per host debugging, as I
> have multiple cards in my systems.    There are several cases I've
> debugged two controller case, when boot OS is on one controller, and the
> debug efforts on another, in that case I only want to concern myself
> with the debug in question, not boot OS.  The method of debug usesage is
> in mptdebug.h, so I would think people would look there, and figure it
> out.  I also have a script below that sets all the host debug sas chips.
> Does this sound reasonable? If not, let me know.
>
> ---[Cut below]---
> #!/bin/bash
> #set -x
> if (( $# != 1 )); then
> 	echo -e \\n"useage: set_debug_level <level>"
> 	echo -e \\n
> 	exit 1
> fi
>
> scsi_host="/sys/class/scsi_host"
> cd ${scsi_host}
> subfolders=`ls -1`
> for i in ${subfolders};  do
> 	cd ${i}
> 	if [ `cat proc_name` != "mptsas" ]; then
> 		cd ${scsi_host}
> 		continue;
> 	fi;
> 	echo $1 > debug_level
> 	debug_level=`cat debug_level`
> 	echo for ${i} debug_level=$debug_level
> 	cd ${scsi_host}
> done;
> ---[Cut above]---

 	Sure would be nice if this tool worked for scsi hosts instead of just 
sas .  At least that's the way it looks to me .

# ls -1 /sys/class/scsi_host
host0/
host1/
host2/
host3/
host4/
host5/

 	The "if [ `cat proc_name` != "mptsas" ]; then ... fi" section seems to 
preclude the ability to set the debug level when using a non-mptsas host adapter .
 	ie:
# cat host*/proc_name
aic79xx
aic79xx
mptspi
mptspi
mptspi
mptspi

 		Hth ,  JimL

ps:	Might be nice to get your input back on the other notes I've sent .
-- 
+-----------------------------------------------------------------+
| James   W.   Laferriere | System   Techniques | Give me VMS     |
| Network        Engineer | 663  Beaumont  Blvd |  Give me Linux  |
| babydr@baby-dragons.com | Pacifica, CA. 94044 |   only  on  AXP |
+-----------------------------------------------------------------+