mpt fusion: Add logging support

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

(quoted diff) +0 -0

 	[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

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?

Quoted 4 lines · 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

Quoted 5 lines

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

Quoted 11 lines

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.

Quoted 11 lines · Eric

Quoted 9 lines · 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).

Quoted 2 lines

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.

Quoted 7 lines

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

Quoted 1 line

On another note, while unloading the driver, and I get an

following opps

Quoted 3 lines

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

Quoted 19 lines

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 <[email protected]>
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 <[email protected]>

Quoted 32 lines · FUJITA Tomonori

Quoted 1 line

On another note, while unloading the driver, and I get an

following opps

Quoted 3 lines

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

Quoted 19 lines

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 <[email protected]>
Subject: [PATCH] scsi_transport_sas: initialize sas_host_attrs->q

Quoted 3 lines

fix the bug to call bsg_unregister_queue for an uninitialized queue.

Signed-off-by FUJITA Tomonori <[email protected]>

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.

Quoted 8 lines · 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.

Quoted 9 lines

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