Re: [Bugme-new] [Bug 8989] New: LSIFC909 card don't recognice any more my FC drives
On Fri, 7 Sep 2007 05:42:12 -0700 (PDT) [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=8989 > >Summary: LSIFC909 card don't recognice any more my FC drives >Product: Drivers >Version: 2.5 > KernelVersion: 2.6.18 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Other > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > > > Hello, > > I had upgraded my server from debian sarge (kernel 2.6.8) to debian etch > (kernel 2.6.18). > Since this upgrade I can't any more see my fc-drives. I get no failures > during the system boot. > It seems that the card would be reginized correct, but as I wrote, I > can't see any drives. > When I boot the server with debian sarge (kernel 2.6.8) all works > fine ..;-) > I had compile a new kernel 2.6.22.6 also with MPT- direct compiled into > the kernel (not as moduls) and tries with them also.. but no success. > > Here is my config: > HBA: LSIFC909 > Disk: 1 x SEGATE CHEETAH 18 GB 10Krpm + 2 x HITACHI 146GB 15Krpm drives > in AL (works fine with kernel 2.6.8...) > > I send you here any logs: > lspci: > 00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM > Controller/Host-Hub Interface (rev 02) > 00:01.0 PCI bridge: Intel Corporation 82865G/PE/P PCI to AGP Controller > (rev 02) > 00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB > UHCI Controller #1 (rev 02) > 00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB > UHCI Controller #2 (rev 02) > 00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB > UHCI Controller #3 (rev 02) > 00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB > UHCI Controller #4 (rev 02) > 00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 > EHCI Controller (rev 02) > 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2) > 00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC > Interface Bridge (rev 02) > 00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE > Controller (rev 02) > 00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus > Controller (rev 02) > 01:00.0 VGA compatible controller: nVidia Corporation NV20 [GeForce3 Ti > 500] (rev a3) > 02:02.0 SCSI storage controller: LSI Logic / Symbios Logic FC909 Fibre > Channel Adapter (rev 01) > 02:04.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev > 0a) > 02:04.1 Input device controller: Creative Labs SB Live! Game Port (rev > 0a) > 02:08.0 Ethernet controller: Intel Corporation 82562EZ 10/100 Ethernet > Controller (rev 02) > > /var/log/messages: (debuging enabled > in /usr/src/linux/drivers/message/fusion/Makefile: EXTRA_CFLAGS += > -DMPT_DEBUG_INIT) > > .. > Sep 6 09:47:10 localhost kernel: Copyright (c) 1999-2005 LSI Logic > Corporation > Sep 6 09:49:22 localhost kernel: mptscsih: Unknown symbol > scsi_remove_host > Sep 6 09:49:22 localhost kernel: mptscsih: Unknown symbol scsi_host_put > Sep 6 09:49:22 localhost kernel: mptscsih: Unknown symbol > scsi_print_command > Sep 6 09:49:22 localhost kernel: mptscsih: Unknown symbol > scsi_adjust_queue_depth > Sep 6 09:50:09 localhost kernel: SCSI subsystem initialized > Sep 6 09:50:53 localhost kernel: mptfc: Unknown symbol > fc_attach_transport > Sep 6 09:50:53 localhost kernel: mptfc: Unknown symbol > fc_remote_port_add > Sep 6 09:50:53 localhost kernel: mptfc: Unknown symbol fc_remove_host > Sep 6 09:50:53 localhost kernel: mptfc: Unknown symbol > fc_remote_port_delete > Sep 6 09:50:53 localhost kernel: mptfc: Unknown symbol > fc_release_transport > Sep 6 09:50:53 localhost kernel: mptfc: Unknown symbol > fc_remote_port_rolechg > Sep 6 09:50:53 localhost kernel: mptfc: Unknown symbol scsi_is_fc_rport > Sep 6 09:51:28 localhost kernel: Fusion MPT misc device (ioctl) driver > 3.04.01 > Sep 6 09:51:28 localhost kernel: mptctl: Registered with Fusion MPT > base driver > Sep 6 09:51:28 localhost kernel: mptctl: /dev/mptctl @ > (major,minor=10,220) > Sep 6 09:52:08 localhost kernel: Fusion MPT FC Host driver 3.04.01 > Sep 6 09:52:08 localhost kernel: mptbase: Initiating ioc0 bringup > Sep 6 09:52:09 localhost kernel: scsi0 : ioc0: LSIFC909, > FwRev=0100h, Ports=1, MaxQ=1023, IRQ=201 > Sep 6 09:54:37 localhost mpt-statusd: detected non-optimal RAID status > > > loaded modules: > mptfc 14468 0 > mptscsih 21696 1 mptfc > mptbase46176 2 mptfc,mptscsih > scsi_transport_fc 28544 1 mptfc > scsi_mod 124168 3 mptfc,mptscsih,scsi_transport_fc > > > -- > 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
RE: [PATCH] aic94xx: fix smartctl utility problem
Hi Jeff,
Thanks for your suggestions. I have done some experiment to return all
ATA output register except for Read/Write command. But the aic94xx
discovery machine just can not find the SATA device. Probably I will fix
the new issue by next week since I have the other hot issue here.
Thanks!
Gilbert
-Original Message-
From: Jeff Garzik [mailto:[EMAIL PROTECTED]
Sent: Friday, September 07, 2007 4:01 PM
To: Wu, Gilbert
Cc: Linux-scsi@vger.kernel.org
Subject: Re: [PATCH] aic94xx: fix smartctl utility problem
Wu, Gilbert wrote:
> HI Jeff,
>
> I was thinking the checking "READ/WRITE" command table is larger
than
> my current table. This does not cover vendor-specific command.
You can implement the check in a _far_ more optimal manner:
Possibility 1:
static const u8 ata_rw_command_table[256] = {
[ATA_CMD_READ] = 1,
[ATA_CMD_READ_EXT] = 1,
... other READ/WRITE commands here, always value==1 ...
};
...
u8 ata_command = ... ;
if (ata_rw_command_table[ata_command]) {
/* it is a read/write command */
} else {
/* it is NOT a read/write command */
}
Possibility 2:
static inline int is_ata_rw_cmd(u8 ata_cmd)
{
switch (ata_cmd) {
case ATA_CMD_READ:
case ATA_CMD_READ_EXT:
... other READ/WRITE commands here ...
return 1;
}
return 0;
}
Either way you avoid the iteration, and simplify things down to a single
test.
Once that is done, it should be self-evident that testing -any- list of
commands is O(1), rather than O(n) for the case of table iteration. And
therefore, the cost of checking "is it a READ/WRITE command?" is equal
to the cost of checking for any other commands.
> Do you wan me just check READ/WRITE command?
Yes, please.
> The aic94xx default implementation is all ATA command will be
returning
> ATA output register if the command did not succeed.
Great!
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
Wu, Gilbert wrote:
HI Jeff,
I was thinking the checking "READ/WRITE" command table is larger than
my current table. This does not cover vendor-specific command.
You can implement the check in a _far_ more optimal manner:
Possibility 1:
static const u8 ata_rw_command_table[256] = {
[ATA_CMD_READ] = 1,
[ATA_CMD_READ_EXT] = 1,
... other READ/WRITE commands here, always value==1 ...
};
...
u8 ata_command = ... ;
if (ata_rw_command_table[ata_command]) {
/* it is a read/write command */
} else {
/* it is NOT a read/write command */
}
Possibility 2:
static inline int is_ata_rw_cmd(u8 ata_cmd)
{
switch (ata_cmd) {
case ATA_CMD_READ:
case ATA_CMD_READ_EXT:
... other READ/WRITE commands here ...
return 1;
}
return 0;
}
Either way you avoid the iteration, and simplify things down to a single
test.
Once that is done, it should be self-evident that testing -any- list of
commands is O(1), rather than O(n) for the case of table iteration. And
therefore, the cost of checking "is it a READ/WRITE command?" is equal
to the cost of checking for any other commands.
Do you wan me just check READ/WRITE command?
Yes, please.
The aic94xx default implementation is all ATA command will be returning
ATA output register if the command did not succeed.
Great!
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 v3 2/2][BNX2]: Add iSCSI support to BNX2 devices.
Anil Veerabhadrappa wrote:
+
+/* iSCSI stages */
+#define ISCSI_STAGE_SECURITY_NEGOTIATION (0)
+#define ISCSI_STAGE_LOGIN_OPERATIONAL_NEGOTIATION (1)
+#define ISCSI_STAGE_FULL_FEATURE_PHASE (3)
+/* Logout response codes */
+#define ISCSI_LOGOUT_RESPONSE_CONNECTION_CLOSED (0)
+#define ISCSI_LOGOUT_RESPONSE_CID_NOT_FOUND (1)
+#define ISCSI_LOGOUT_RESPONSE_CLEANUP_FAILED (3)
+
+/* iSCSI task types */
+#define ISCSI_TASK_TYPE_READ(0)
+#define ISCSI_TASK_TYPE_WRITE (1)
+#define ISCSI_TASK_TYPE_MPATH (2)
All of these iscsi code shoulds be in iscsi_proto.h or should be added
there.
This is a very tricky proposal as this header file is automatically
generated by a well defined process and is shared between various driver
supporting multiple platform/OS and the firmware. If it is not of a big
issue I would like to keep it the way it is.
The values that are iscsi RFC values should come from the iscsi_proto.h
file and not be duplicated for each driver.
+/*
+ * hardware reset
+ */
+int bnx2i_reset(struct scsi_cmnd *sc)
+{
+ return 0;
+}
So what is up with this one? It seems like if there is a way to reset
hardware then you would want it as the scsi eh host reset callout
instead of dropping the session. We could add some transport level
recovery callouts for the iscsi specifics.
We may not be able to support HBA cold reset as bnx2 driver is the
primary owner of chip reset and initialization. This is the drawback of
sharing network interface with the NIC driver. If there is a need for
administrator to reset the iSCSI port same can be achieved by running
'ifdown eth#' and 'ifup eth#'.
Current driver even allows ethernet interface reset when there are
active iSCSI connection, all active iscsi sessions will be reinstated
when the network link comes back live
If you cannot support it or it does not make sense just remove the stub
then. I say it is not a big deal now, but hopefully we do not hit fun
like with qla3xxx and qla4xxx :)
+
+void bnx2i_sysfs_cleanup(void)
+{
+ class_device_unregister(&port_class_dev);
+ class_unregister(&bnx2i_class);
+}
The sysfs bits related to the hba should be use one of the scsi sysfs
facilities or if they are related to iscsi bits and are generic then
through the iscsi hba
bnx2i needs 2 sysfs entries -
1. QP size info - this is used to size per connection shared data
structures to issue work requests to chip (login, scsi cmd, tmf, nopin)
and get completions from the chip (scsi completions, async messages,
etc'). This is a iSCSI HBA attribute
2. port mapper - we can be more flexible on classifying this as either
iSCSI HBA attribute or bnx2i driver global attribute
Can hooks be added to iSCSI transport class to include these?
Which ones were they exactly? I think JamesB wanted only common
transport values in the transport class. If it is driver specific then
it should go on the host or target or device with the scsi_host_template
attrs.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linux-usb-users] usb-storage and Motorola Z6
On Fri, 7 Sep 2007, Peter Rasmussen wrote: > I'm sorry if this is a little late, but I had once had access to a Z6 > and believe I had it successfully connected to my Linux host, and was > therefore puzzled by this message exchange. > > I have now borrowed the device again for the weekend to check it out a > little more. > > Using Alan's patch below, otherwise my kernel is a standard 2.6.23-rc5 > (CONFIG_USB_STORAGE_DEBUG=y ) I got the following result after reboot > and connecting the Z6.: ... In fact there was another patch from earlier in the email thread, which was needed to work around the PQ = 1 problem. Since you didn't apply that patch, the SCSI disk driver wasn't bound to your Z6. > What I can't understand, however, is that as this mobile phone > supposedly runs Linux. I can't see how Motorola could break it so badly > that the USB connection now doesn't work with a PC running Linux? :-) There's no necessary relation between the OS running on a device like your phone and its interoperability with computers running the same OS. > And you say that this seems to be a more widespread problem with > Motorola devices? Do you remember which ones, and do they run Linux as well? There were two problems. First was the PQ = 1 problem; I have never seen it before now (so only on the Z6). The other problem was the capacity, or last sector number; we know that the RAZR V3i and V3x both suffer from it as well. (I have no idea whether they run Linux.) Possibly other devices do too, and we just don't know about them. > The following is from connecting a Z3 that supposedly isn't based on > Linux, but works all right (and this may have been the one I thought was > the Z6 that I claimed worked): ... It looks normal. > I hope perhaps it can provide some comparison info now with a device > that works and one that doesn't. > > If Motorola actualy has made changes to the Linux kernel they use with > the Z6, I suppose we should be able to get the actual code. Should I > investigate that? Sure, go ahead and try. Maybe you can convince them to fix their bugs! Although that won't help all the units that have already been manufactured... 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: [Linux-usb-users] usb-storage and Motorola Z6
I'm sorry if this is a little late, but I had once had access to a Z6 and believe I had it successfully connected to my Linux host, and was therefore puzzled by this message exchange. I have now borrowed the device again for the weekend to check it out a little more. Using Alan's patch below, otherwise my kernel is a standard 2.6.23-rc5 (CONFIG_USB_STORAGE_DEBUG=y ) I got the following result after reboot and connecting the Z6.: ohci_hcd :00:02.0: auto-wakeup root hub hub 1-0:1.0: state 7 ports 3 chg evt 0002 ohci_hcd :00:02.0: GetStatus roothub.portstatus [0] = 0x00010101 CSC PPS CCS hub 1-0:1.0: port 1, status 0101, change 0001, 12 Mb/s hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x101 ohci_hcd :00:02.0: GetStatus roothub.portstatus [0] = 0x00100103 PRSC PPS PES CCS usb 1-1: new full speed USB device using ohci_hcd and address 2 ohci_hcd :00:02.0: GetStatus roothub.portstatus [0] = 0x00100103 PRSC PPS PES CCS usb 1-1: default language 0x0409 usb 1-1: new device strings: Mfr=3, Product=2, SerialNumber=4 usb 1-1: Product: MS usb 1-1: Manufacturer: Motorola Inc. usb 1-1: SerialNumber: 901324BA0C2005 usb 1-1: uevent usb 1-1: usb_probe_device usb 1-1: configuration #1 chosen from 1 choice usb 1-1: adding 1-1:1.0 (config #1, interface 0) usb 1-1:1.0: uevent usb 1-1:1.0: uevent usb-storage 1-1:1.0: usb_probe_interface usb-storage 1-1:1.0: usb_probe_interface - got id usb-storage: USB Mass Storage device detected usb-storage: -- associate_dev usb-storage: Vendor: 0x22b8, Product: 0x6426, Revision: 0x0101 usb-storage: Interface Subclass: 0x06, Protocol: 0x50 usb-storage: Transport: Bulk usb-storage: Protocol: Transparent SCSI scsi0 : SCSI emulation for USB Mass Storage devices usb-storage: *** thread sleeping. usb-storage: device found at 2 usb-storage: waiting for device to settle before scanning drivers/usb/core/inode.c: creating file '002' hub 1-0:1.0: state 7 ports 3 chg evt 0002 usb-storage: usb_stor_control_msg: rq=fe rqtype=a1 value= index=00 len=1 usb-storage: GetMaxLUN command result is 1, data is 1 usb-storage: queuecommand called usb-storage: *** thread awakened. usb-storage: Command INQUIRY (6 bytes) usb-storage: 12 00 00 00 24 00 usb-storage: Bulk Command S 0x43425355 T 0x1 L 36 F 128 Trg 0 LUN 0 CL 6 usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes usb-storage: Status code 0; transferred 31/31 usb-storage: -- transfer complete usb-storage: Bulk command transfer result=0 usb-storage: usb_stor_bulk_transfer_sglist: xfer 36 bytes, 1 entries usb-storage: Status code 0; transferred 36/36 usb-storage: -- transfer complete usb-storage: Bulk data transfer result 0x0 usb-storage: Attempting to get CSW... usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes usb-storage: Status code 0; transferred 13/13 usb-storage: -- transfer complete usb-storage: Bulk status result = 0 usb-storage: Bulk Status S 0x53425355 T 0x1 R 0 Stat 0x0 usb-storage: scsi cmd done, result=0x0 usb-storage: *** thread sleeping. scsi 0:0:0:0: Direct-Access Motorola MSnc. PQ: 1 ANSI: 0 CCS scsi 0:0:0:0: Attached scsi generic sg0 type 0 usb-storage: queuecommand called usb-storage: *** thread awakened. usb-storage: Command INQUIRY (6 bytes) usb-storage: 12 00 00 00 24 00 usb-storage: Bulk Command S 0x43425355 T 0x2 L 36 F 128 Trg 0 LUN 1 CL 6 usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes usb-storage: Status code 0; transferred 31/31 usb-storage: -- transfer complete usb-storage: Bulk command transfer result=0 usb-storage: usb_stor_bulk_transfer_sglist: xfer 36 bytes, 1 entries usb-storage: Status code 0; transferred 36/36 usb-storage: -- transfer complete usb-storage: Bulk data transfer result 0x0 usb-storage: Attempting to get CSW... usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes usb-storage: Status code 0; transferred 13/13 usb-storage: -- transfer complete usb-storage: Bulk status result = 0 usb-storage: Bulk Status S 0x53425355 T 0x2 R 0 Stat 0x0 usb-storage: scsi cmd done, result=0x0 usb-storage: *** thread sleeping. scsi 0:0:0:1: Direct-Access Motorola MSnc. PQ: 1 ANSI: 0 CCS scsi 0:0:0:1: Attached scsi generic sg1 type 0 usb-storage: queuecommand called usb-storage: *** thread awakened. usb-storage: Bad LUN (0:2) usb-storage: scsi cmd done, result=0x4 usb-storage: *** thread sleeping. usb-storage: queuecommand called usb-storage: *** thread awakened. usb-storage: Bad target number (1:0) usb-storage: scsi cmd done, result=0x4 usb-storage: *** thread sleeping. usb-storage: queuecommand called usb-storage: *** thread awakened. usb-storage: Bad target number (2:0) usb-storage: scsi cmd done, result=0x4 usb-storage: *** thread sleeping. usb-storage: queuecommand called usb-storage: *** thread awakened. usb-storage: Bad target number (3:0) usb-storage: scsi cmd done, result=0x4 usb-storage: *** thread sleeping. usb-storage: queuecommand called usb-storage: *** thread awakened. usb-stora
Re: [PATCH 4/9] scsi_debug: convert to use the data buffer accessors
FUJITA Tomonori wrote: > From: Boaz Harrosh <[EMAIL PROTECTED]> > > - remove the unnecessary map_single path. > > - convert to use the new accessors for the sg lists and the > parameters. > > Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]> Signed-off-by: Douglas Gilbert <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] zfcp: zfcp: add statistics and other zfcp relatedinformation to sysfs
I am afraid this patch can't be applied as it is.
The problem is that the code doesn't take into account that older adapters do
not provide the data which your patch tries to extract. There is a feature flag
for that in the hardware specification. So the right response to Heiko's
complaint about an unused feature flag wasn't to remove the flag definition... :-)
Is this patch against 2.6.23-rc or something? It doesn't apply without some
minor noise. Besides there are some "HEAD"s below, which makes me think this is
against some internal CVS revision...
For more nit-picking please see below.
Thanks,
Martin
Swen Schillig wrote:
From: Swen Schillig <[EMAIL PROTECTED]>
add statistics and other zfcp related information to sysfs
The zfcp adapter provides a variety of information which was never
published to the external world. This patch adds a few of those "statistics"
to the sysfs tree structure.
These are reflected in the following attributes
/sys/bus/ccw/drivers/zfcp/0.0.1707
/* information for the virtual adapter */
statistic_services/
requests
megabytes
utilization
seconds_active
/* LUN specific info for channel- and fabric-latency */
0x500507630300c562/0x401040a6/
read_latency
write_latency
cmd_latency
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/Makefile|2
drivers/s390/scsi/zfcp_aux.c | 30 -
drivers/s390/scsi/zfcp_def.h | 14 ++
drivers/s390/scsi/zfcp_ext.h |2
drivers/s390/scsi/zfcp_fsf.c |1
drivers/s390/scsi/zfcp_fsf.h | 28 -
drivers/s390/scsi/zfcp_qdio.c | 39 +++
drivers/s390/scsi/zfcp_sysfs_statistics.c | 162 ++
drivers/s390/scsi/zfcp_sysfs_unit.c | 63 +++
9 files changed, 333 insertions(+), 8 deletions(-)
Index: HEAD/drivers/s390/scsi/zfcp_def.h
===
--- HEAD.orig/drivers/s390/scsi/zfcp_def.h
+++ HEAD/drivers/s390/scsi/zfcp_def.h
@@ -868,6 +868,17 @@ struct zfcp_erp_action {
struct timer_list timer;
};
+struct latency_cont {
+ u32 channel;
+ u32 fabric;
+ u32 counter;
+};
Are you sure you want just 32 bits for sums? Given the unit used (hw ticks) it
overruns quickly.
+
+struct zfcp_latencies {
+ struct latency_cont read;
+ struct latency_cont write;
+ struct latency_cont cmd;
+};
struct zfcp_adapter {
struct list_headlist; /* list of adapters */
@@ -883,6 +894,7 @@ struct zfcp_adapter {
u32 adapter_features; /* FCP channel features */
u32 connection_features; /* host connection
features */
u32hardware_version; /* of FCP channel */
+ u16 timer_ticks; /* time int for a tick */
struct Scsi_Host*scsi_host;/* Pointer to mid-layer */
struct list_headport_list_head;/* remote port list */
struct list_headport_remove_lh;/* head of ports to be
@@ -930,6 +942,7 @@ struct zfcp_adapter {
struct zfcp_scsi_dbf_record scsi_dbf_buf;
struct zfcp_adapter_mempool pool; /* Adapter memory pools */
struct qdio_initialize qdio_init_data;/* for qdio_establish */
+ struct device stat_services;
After my fancy, stat_services is not a good choice. Shorten it; statistics is
descriptive enough.
In case you have been inspired by generic_services below: generic_services
refers to Generic Services (GS) as defined by FC standard documents.
struct device generic_services; /* directory for WKA ports */
struct fc_host_statistics *fc_stats;
struct fsf_qtcb_bottom_port *stats_reset_data;
@@ -986,6 +999,7 @@ struct zfcp_unit {
all scsi_scan_target
requests have been
completed. */
+ struct zfcp_latencies latencies;
};
/* FSF request */
Index: HEAD/drivers/s390/scsi/zfcp_fsf.c
===
--- HEAD.orig/drivers/s390/scsi/zfcp_fsf.c
+++ HEAD/drivers/s390/scsi/zfcp_fsf.c
@@ -2079,6 +2079,7 @@ zfcp_fsf_exchange_config_evaluate(struct
fc_host_supported_classes(shost) =
FC_COS_CLASS2 | FC_COS_CLASS3;
adapter->hydra_version = bottom->adapter_type;
+ adapter->timer_ticks = bottom->timer_interval;
if (fc_host_permanent_port_name(shost) == -1)
fc_host_permanent_port_name(shost) =
fc_host_port_
[PATCH 1/2] zfcp: whitespace cleanup
From: Swen Schillig <[EMAIL PROTECTED]>
Cleanup the whitepace from the entire zfcp driver to prevent
to have those changes in future feature or function patches.
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_aux.c|4 -
drivers/s390/scsi/zfcp_def.h| 46 ++--
drivers/s390/scsi/zfcp_erp.c| 134 ++--
drivers/s390/scsi/zfcp_ext.h| 30
drivers/s390/scsi/zfcp_fsf.c| 40 +-
drivers/s390/scsi/zfcp_fsf.h| 30
drivers/s390/scsi/zfcp_qdio.c |7 -
drivers/s390/scsi/zfcp_scsi.c | 36 -
drivers/s390/scsi/zfcp_sysfs_unit.c |4 -
9 files changed, 165 insertions(+), 166 deletions(-)
Index: HEAD/drivers/s390/scsi/zfcp_aux.c
===
--- HEAD.orig/drivers/s390/scsi/zfcp_aux.c
+++ HEAD/drivers/s390/scsi/zfcp_aux.c
@@ -891,7 +891,7 @@ zfcp_unit_dequeue(struct zfcp_unit *unit
/*
* Allocates a combined QTCB/fsf_req buffer for erp actions and fcp/SCSI
* commands.
- * It also genrates fcp-nameserver request/response buffer and unsolicited
+ * It also genrates fcp-nameserver request/response buffer and unsolicited
* status read fsf_req buffers.
*
* locks: must only be called with zfcp_data.config_sema taken
@@ -982,7 +982,7 @@ zfcp_adapter_enqueue(struct ccw_device *
struct zfcp_adapter *adapter;
/*
-* Note: It is safe to release the list_lock, as any list changes
+* Note: It is safe to release the list_lock, as any list changes
* are protected by the config_sema, which must be held to get here
*/
Index: HEAD/drivers/s390/scsi/zfcp_def.h
===
--- HEAD.orig/drivers/s390/scsi/zfcp_def.h
+++ HEAD/drivers/s390/scsi/zfcp_def.h
@@ -1,23 +1,23 @@
-/*
+/*
* This file is part of the zfcp device driver for
* FCP adapters for IBM System z9 and zSeries.
*
* (C) Copyright IBM Corp. 2002, 2006
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2, or (at your option)
- * any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- */
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
#ifndef ZFCP_DEF_H
#define ZFCP_DEF_H
@@ -90,7 +90,7 @@ zfcp_address_to_sg(void *address, struct
#define ZFCP_DEVICE_TYPE0x1732
#define ZFCP_DEVICE_MODEL 0x03
#define ZFCP_DEVICE_MODEL_PRIV 0x04
-
+
/* allow as many chained SBALs as are supported by hardware */
#define ZFCP_MAX_SBALS_PER_REQ FSF_MAX_SBALS_PER_REQ
#define ZFCP_MAX_SBALS_PER_CT_REQ FSF_MAX_SBALS_PER_REQ
@@ -508,7 +508,7 @@ struct zfcp_rc_entry {
/*
* this allows removal of logging code by the preprocessor
- * (the most detailed log level still to be compiled in is specified,
+ * (the most detailed log level still to be compiled in is specified,
* higher log levels are removed)
*/
#define ZFCP_LOG_LEVEL_LIMIT ZFCP_LOG_LEVEL_TRACE
@@ -546,7 +546,7 @@ do { \
if (ZFCP_LOG_CHECK(level)) \
_ZFCP_LOG(fmt, ##args); \
} while (0)
-
+
#if ZFCP_LOG_LEVEL_LIMIT < ZFCP_LOG_LEVEL_NORMAL
# define ZFCP_LOG_NORMAL(fmt, args...) do { } while (0)
#else
@@ -583,8 +583,8 @@ do { \
/*** ADAPTER/PORT/UNIT AND FSF_REQ STATUS FLAGS **/
-/*
- * Note, the leftmost status byte is common among adapter, port
+/*
+ * Note, the leftmost status byte is common among adapter, port
* and unit
*/
#define ZFCP_COMMON_FLAGS 0xfff0
@@ -1007,8 +1007,8 @@ struct zfcp_fsf_req {
u32fsf_command;/* FSF Command copy */
struct fsf_qtcb*qtcb; /* address
[PATCH 2/2] zfcp: zfcp: add statistics and other zfcp relatedinformation to sysfs
From: Swen Schillig <[EMAIL PROTECTED]>
add statistics and other zfcp related information to sysfs
The zfcp adapter provides a variety of information which was never
published to the external world. This patch adds a few of those "statistics"
to the sysfs tree structure.
These are reflected in the following attributes
/sys/bus/ccw/drivers/zfcp/0.0.1707
/* information for the virtual adapter */
statistic_services/
requests
megabytes
utilization
seconds_active
/* LUN specific info for channel- and fabric-latency */
0x500507630300c562/0x401040a6/
read_latency
write_latency
cmd_latency
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/Makefile|2
drivers/s390/scsi/zfcp_aux.c | 30 -
drivers/s390/scsi/zfcp_def.h | 14 ++
drivers/s390/scsi/zfcp_ext.h |2
drivers/s390/scsi/zfcp_fsf.c |1
drivers/s390/scsi/zfcp_fsf.h | 28 -
drivers/s390/scsi/zfcp_qdio.c | 39 +++
drivers/s390/scsi/zfcp_sysfs_statistics.c | 162 ++
drivers/s390/scsi/zfcp_sysfs_unit.c | 63 +++
9 files changed, 333 insertions(+), 8 deletions(-)
Index: HEAD/drivers/s390/scsi/zfcp_def.h
===
--- HEAD.orig/drivers/s390/scsi/zfcp_def.h
+++ HEAD/drivers/s390/scsi/zfcp_def.h
@@ -868,6 +868,17 @@ struct zfcp_erp_action {
struct timer_list timer;
};
+struct latency_cont {
+ u32 channel;
+ u32 fabric;
+ u32 counter;
+};
+
+struct zfcp_latencies {
+ struct latency_cont read;
+ struct latency_cont write;
+ struct latency_cont cmd;
+};
struct zfcp_adapter {
struct list_headlist; /* list of adapters */
@@ -883,6 +894,7 @@ struct zfcp_adapter {
u32 adapter_features; /* FCP channel features */
u32 connection_features; /* host connection
features */
u32hardware_version; /* of FCP channel */
+ u16 timer_ticks; /* time int for a tick */
struct Scsi_Host*scsi_host;/* Pointer to mid-layer */
struct list_headport_list_head;/* remote port list */
struct list_headport_remove_lh;/* head of ports to be
@@ -930,6 +942,7 @@ struct zfcp_adapter {
struct zfcp_scsi_dbf_record scsi_dbf_buf;
struct zfcp_adapter_mempool pool; /* Adapter memory pools */
struct qdio_initialize qdio_init_data;/* for qdio_establish */
+ struct device stat_services;
struct device generic_services; /* directory for WKA ports */
struct fc_host_statistics *fc_stats;
struct fsf_qtcb_bottom_port *stats_reset_data;
@@ -986,6 +999,7 @@ struct zfcp_unit {
all scsi_scan_target
requests have been
completed. */
+ struct zfcp_latencies latencies;
};
/* FSF request */
Index: HEAD/drivers/s390/scsi/zfcp_fsf.c
===
--- HEAD.orig/drivers/s390/scsi/zfcp_fsf.c
+++ HEAD/drivers/s390/scsi/zfcp_fsf.c
@@ -2079,6 +2079,7 @@ zfcp_fsf_exchange_config_evaluate(struct
fc_host_supported_classes(shost) =
FC_COS_CLASS2 | FC_COS_CLASS3;
adapter->hydra_version = bottom->adapter_type;
+ adapter->timer_ticks = bottom->timer_interval;
if (fc_host_permanent_port_name(shost) == -1)
fc_host_permanent_port_name(shost) =
fc_host_port_name(shost);
Index: HEAD/drivers/s390/scsi/zfcp_fsf.h
===
--- HEAD.orig/drivers/s390/scsi/zfcp_fsf.h
+++ HEAD/drivers/s390/scsi/zfcp_fsf.h
@@ -322,11 +322,18 @@ struct fsf_link_down_info {
u8 vendor_specific_code;
} __attribute__ ((packed));
+struct fsf_qual_latency_info {
+ u32 channel_lat;
+ u32 fabric_lat;
+ u8 res1[8];
+} __attribute__ ((packed));
+
union fsf_prot_status_qual {
u64 doubleword[FSF_PROT_STATUS_QUAL_SIZE / sizeof(u64)];
struct fsf_qual_version_error version_error;
struct fsf_qual_sequence_error sequence_error;
struct fsf_link_down_info link_down_info;
+ struct fsf_qual_latency_info latency_info;
} __attribute__ ((packed));
struct fsf_qtcb_prefix {
@@ -340,6 +347,15 @@ struct fsf_qtcb_prefix {
u8 res1[20];
} __attribute__ ((packed));
+struct fsf_statistics_info {
+ u64 input_req;
+ u64 output_req;
+ u64 c
[PATCH 0/2] zfcp: cleanup and add statistics
James please drop my first attempt for the zfcp add statistics patch and instead use the 2 which are following. Patch 1: whitespace cleanup. Patch 2: the modified zfcp add statistics patch This patchset was created due to the comments from Heiko Carstens pointing out a few things which could be improved. Sorry, for the inconvenience. Cheers Swen. - 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
