RE: As of 2.6.13-rc1 Fusion-MPT very slow
> This is alive and well in 2.6.13 (final) on ia64. Or perhaps not. When I went into the machine room to take a look at this machine, I found that the disk drive in question was making some very bad noises. A few minutes later it stopped responding at all. Putting in a new drive, I see a consistent 51 MB/s on /dev/sdb Sorry for the noise. -Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: As of 2.6.13-rc1 Fusion-MPT very slow
This is alive and well in 2.6.13 (final) on ia64. Excerpts from dmesg
when booting:
Fusion MPT base driver 3.03.02
Copyright (c) 1999-2005 LSI Logic Corporation
Fusion MPT SPI Host driver 3.03.02
GSI 28 (level, low) -> CPU 1 (0xc218) vector 49
ACPI: PCI Interrupt :06:02.0[A] -> GSI 28 (level, low) -> IRQ 49
mptbase: Initiating ioc0 bringup
ioc0: 53C1030: Capabilities={Initiator}
scsi0 : ioc0: LSI53C1030, FwRev=01030a00h, Ports=1, MaxQ=255, IRQ=49
Vendor: QUANTUM Model: ATLAS IV 9 SCARev: 0B0B
Type: Direct-Access ANSI SCSI revision: 03
SCSI device sda: 17942584 512-byte hdwr sectors (9187 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 17942584 512-byte hdwr sectors (9187 MB)
SCSI device sda: drive cache: write back
sda: sda1 sda2 sda3
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Vendor: MAXTORModel: ATLAS10K4_73SCA Rev: DFV0
Type: Direct-Access ANSI SCSI revision: 03
SCSI device sdb: 143666192 512-byte hdwr sectors (73557 MB)
SCSI device sdb: drive cache: write back
SCSI device sdb: 143666192 512-byte hdwr sectors (73557 MB)
SCSI device sdb: drive cache: write back
sdb: sdb1
Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0
Vendor: ESG-SHV Model: SCA HSBP M17 Rev: 1.0D
Type: Processor ANSI SCSI revision: 02
GSI 29 (level, low) -> CPU 2 (0xc418) vector 50
ACPI: PCI Interrupt :06:02.1[B] -> GSI 29 (level, low) -> IRQ 50
mptbase: Initiating ioc1 bringup
ioc1: 53C1030: Capabilities={Initiator}
scsi1 : ioc1: LSI53C1030, FwRev=01030a00h, Ports=1, MaxQ=255, IRQ=50
Fusion MPT FC Host driver 3.03.02
Fusion MPT misc device (ioctl) driver 3.03.02
mptctl: Registered with Fusion MPT base driver
mptctl: /dev/mptctl @ (major,minor=10,220)
When I'm up and running, measure the speed of sda and sdb:
# hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 62 MB in 3.02 seconds = 20.56 MB/sec
[This is VERY consistent from run to run, 20.56 MB/s every time].
# hdparm -t /dev/sdb
/dev/sdb:
Timing buffered disk reads:2 MB in 4.04 seconds = 53.79 kB/sec
[Speed on sdb is very erratic ... 53.79 KB/s is the worst I saw in half
a dozen tests ... but first try after boot was 47.14 MB/s, and I see
intermediate rates all over the map: 545.42 KB/s, 5.13 MB/s, 32.61 MB/s]
dmesg shows some messages like this:
mptscsih: ioc0: >> Attempting task abort! (sc=e001fceb4c80)
mptbase: ioc0: IOCStatus(0x0048): SCSI Task Terminated
mptscsih: ioc0: >> Attempting task abort! (sc=e001fceb5080)
mptbase: ioc0: IOCStatus(0x0048): SCSI Task Terminated
mptscsih: ioc0: >> Attempting task abort! (sc=e001fceb6e80)
mptbase: ioc0: IOCStatus(0x0048): SCSI Task Terminated
mptscsih: ioc0: >> Attempting task abort! (sc=e001fceb7a80)
mptbase: ioc0: IOCStatus(0x0048): SCSI Task Terminated
Sometimes there are floods of these, other times just a few ... e.g. I
saw just those 8 lines after ten iterations of "hdparm -t /dev/hdb".
-Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: As of 2.6.13-rc1 Fusion-MPT very slow
On Mon, 8 Aug 2005, Moore, Eric Dean wrote: On Sunday, August 07, 2005 8:30 AM, James Bottomley wrote: On Sun, 2005-08-07 at 05:59 +, Holger Kiehl wrote: Thanks, removing those it compiles fine. This patch also solves my problem, here the output of dmesg: Well ... the transport class was supposed to help diagnose the problem rather than fix it. However, what it shows is that the original problem is in the fusion internal domain validation somewhere, but that we still don't know where... James I was corresponding to Mr Holger Hiehl in private email. What I understood the problem to be was when he compiled the drivers into the kernel, instead of as modules, we would get some drives negotiating as asyn narrow on the 2nd channel. It's always the first channel that has the problem. There are four disks and the first always negotiated as wide and has the full speed. Disk 2 to 4 are always narrow and give me only 2MB/s. On the 2nd channel everything is always ok, here all 4 disks have the full speed. What I was trying to do was reproduce the issue here, and I was unable to.Has Mr Holger Hiehl tried compiling your patch with the drivers compiled statically into the kernel, instead of modules? It was compilled in statically into the kernel. Anyways - My last suggesting was that he change the scsi cable, and reset the parameters in the bios configuration utility. I don't believe that fixed it. No. I exchanged cables still always the same results. Also on a second system that has identical hardware, as soon as I put kernel 2.6.13-rc1 I get the same problem. Here's my next suggestion. Recompile the driver with domain validation debugging enabled. Then send me the output dmesg so I can analyze it. This brings us closer to the root of the problem, I think. With domain validation debugging enabled, this problem is no longer reliably reproducable. I once even saw that only the forth disk on the first channel had the slow performance. Booting several times, gave me most the time full speed for all four disk on the first channel. But the results where not stable. I then took out some unused drivers (hardware watchdog and IPMI) and the system would always come up with all four disk at full speed. I then removed domain validation debugging but then the problem was there again. So I put in a msleep(2000) in ./drivers/block/elevator.c just after it prints out what elevator it used and enabled domain validation debugging again. Booting with this kernel I managed to capture the debugging output with disk 2 to 4 having only 2MB/s. So I think there is some timing problem, somewhere. I also have the output without the msleep(), that is with all four disk having full speed on the first channel. Please tell me if this is of intrest, then I will post it as well. Thanks, Holger --- Bootdata ok (command line is ro root=/dev/md0) Linux version 2.6.13-rc5-git3 ([EMAIL PROTECTED]) (gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)) #6 SMP Tue Aug 9 11:14:17 GMT 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009a000 (usable) BIOS-e820: 0009a000 - 000a (reserved) BIOS-e820: 000d2000 - 0010 (reserved) BIOS-e820: 0010 - f7f7 (usable) BIOS-e820: f7f7 - f7f76000 (ACPI data) BIOS-e820: f7f76000 - f7f8 (ACPI NVS) BIOS-e820: f7f8 - f800 (reserved) BIOS-e820: fec0 - fec00400 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: fff8 - 0001 (reserved) BIOS-e820: 0001 - 0002 (usable) ACPI: RSDP (v002 PTLTD ) @ 0x000f6a70 ACPI: XSDT (v001 PTLTD XSDT 0x0604 LTP 0x) @ 0xf7f72e3b ACPI: FADT (v003 AMDHAMMER 0x0604 PTEC 0x000f4240) @ 0xf7f72f97 ACPI: SRAT (v001 AMDHAMMER 0x0604 AMD 0x0001) @ 0xf7f75904 ACPI: SSDT (v001 PTLTD POWERNOW 0x0604 LTP 0x0001) @ 0xf7f75a3c ACPI: HPET (v001 AMDHAMMER 0x0604 PTEC 0x) @ 0xf7f75dac ACPI: SSDT (v001 AMD-K8 AMD-ACPI 0x0604 AMD 0x0001) @ 0xf7f75de4 ACPI: SSDT (v001 AMD-K8 AMD-ACPI 0x0604 AMD 0x0001) @ 0xf7f75e81 ACPI: MADT (v001 PTLTD APIC 0x0604 LTP 0x) @ 0xf7f75f1e ACPI: SPCR (v001 PTLTD $UCRTBL$ 0x0604 PTL 0x0001) @ 0xf7f75fb0 ACPI: DSDT (v001 AMD-K8 AMDACPI 0x0604 MSFT 0x010e) @ 0x SRAT: PXM 0 -> APIC 0 -> CPU 0 -> Node 0 SRAT: PXM 1 -> APIC 1 -> CPU 1 -> Node 1 SRAT: PXM 2 -> APIC 2 -> CPU 2 -> Node 2 SRAT: PXM 3 -> APIC 3 -> CPU 3 -> Node 3 SRAT: Node 0 PXM 0 0-9 SRAT: Node 0 PXM 0 0-7fff SRAT: Node 1 PXM 1 8000-f7ff SRAT: Node 2 PXM 2 1-17fff SRAT: Node 3 PXM 3 18000-1 Using 26 for the hash shift. Max add
RE: As of 2.6.13-rc1 Fusion-MPT very slow
On Sunday, August 07, 2005 8:30 AM, James Bottomley wrote: > On Sun, 2005-08-07 at 05:59 +, Holger Kiehl wrote: > > Thanks, removing those it compiles fine. This patch also > solves my problem, > > here the output of dmesg: > > Well ... the transport class was supposed to help diagnose the problem > rather than fix it. > > However, what it shows is that the original problem is in the fusion > internal domain validation somewhere, but that we still don't know > where... > > James > I was corresponding to Mr Holger Hiehl in private email. What I understood the problem to be was when he compiled the drivers into the kernel, instead of as modules, we would get some drives negotiating as asyn narrow on the 2nd channel. What I was trying to do was reproduce the issue here, and I was unable to.Has Mr Holger Hiehl tried compiling your patch with the drivers compiled statically into the kernel, instead of modules? Anyways - My last suggesting was that he change the scsi cable, and reset the parameters in the bios configuration utility. I don't believe that fixed it. Here's my next suggestion. Recompile the driver with domain validation debugging enabled. Then send me the output dmesg so I can analyze it. That is done by modifying the driver makefile, adding the following lines: CFLAGS_mptscsih.o += DMPT_DEBUG_DV CFLAGS_mptscsih.o += DMPT_DEBUG_NEGO - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: As of 2.6.13-rc1 Fusion-MPT very slow
On Sun, 2005-08-07 at 05:59 +, Holger Kiehl wrote: > Thanks, removing those it compiles fine. This patch also solves my problem, > here the output of dmesg: Well ... the transport class was supposed to help diagnose the problem rather than fix it. However, what it shows is that the original problem is in the fusion internal domain validation somewhere, but that we still don't know where... James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: As of 2.6.13-rc1 Fusion-MPT very slow
On Sat, 6 Aug 2005, James Bottomley wrote:
On Sat, 2005-08-06 at 21:12 +, Holger Kiehl wrote:
drivers/message/fusion/mptspi.c:505: error: unknown field
â..get_hold_mcsâ.. specified in initializer
drivers/message/fusion/mptspi.c:505: warning: excess elements in struct
initializer
drivers/message/fusion/mptspi.c:505: warning: (near initialization for
â..mptspi_transport_functionsâ..)
drivers/message/fusion/mptspi.c:506: error: unknown field
â..set_hold_mcsâ.. specified in initializer
drivers/message/fusion/mptspi.c:506: warning: excess elements in struct
initializer
drivers/message/fusion/mptspi.c:506: warning: (near initialization for
â..mptspi_transport_functionsâ..)
drivers/message/fusion/mptspi.c:507: error: unknown field
â..show_hold_mcsâ.. specified in initializer
drivers/message/fusion/mptspi.c:507: warning: excess elements in struct
initializer
drivers/message/fusion/mptspi.c:507: warning: (near initialization for
â..mptspi_transport_functionsâ..)
This is actually because -mm is slightly behind the scsi-misc tree. It
looks like the hold_mcs parameters haven't propagated into the -mm tree
yet. You should be able to correct this by cutting these three lines:
.get_hold_mcs = mptspi_read_parameters,
.set_hold_mcs = mptspi_write_hold_mcs,
.show_hold_mcs = 1,
Out of the code at lines 505-507. You'll get a warning about
mptspi_write_hold_mcs() being defined but not used which you can ignore.
Thanks, removing those it compiles fine. This patch also solves my problem,
here the output of dmesg:
Fusion MPT base driver 3.03.02
Copyright (c) 1999-2005 LSI Logic Corporation
Fusion MPT SPI Host driver 3.03.02
ACPI: PCI Interrupt :02:04.0[A] -> GSI 24 (level, low) -> IRQ 217
mptbase: Initiating ioc0 bringup
ioc0: 53C1030: Capabilities={Initiator,Target}
scsi4 : ioc0: LSI53C1030, FwRev=01032700h, Ports=1, MaxQ=255, IRQ=217
Vendor: FUJITSU Model: MAS3735NP Rev: 0104
Type: Direct-Access ANSI SCSI revision: 03
target4:0:0: Beginning Domain Validation
target4:0:0: Ending Domain Validation
target4:0:0: FAST-160 WIDE SCSI 320.0 MB/s DT IU (6.25 ns, offset 127)
SCSI device sdc: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdc: drive cache: write back
SCSI device sdc: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdc: drive cache: write back
sdc: sdc1
Attached scsi disk sdc at scsi4, channel 0, id 0, lun 0
Vendor: FUJITSU Model: MAS3735NP Rev: 0104
Type: Direct-Access ANSI SCSI revision: 03
target4:0:1: Beginning Domain Validation
target4:0:1: Ending Domain Validation
target4:0:1: FAST-160 WIDE SCSI 320.0 MB/s DT IU (6.25 ns, offset 127)
SCSI device sdd: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdd: drive cache: write back
SCSI device sdd: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdd: drive cache: write back
sdd: sdd1
Attached scsi disk sdd at scsi4, channel 0, id 1, lun 0
Vendor: FUJITSU Model: MAS3735NP Rev: 0104
Type: Direct-Access ANSI SCSI revision: 03
target4:0:2: Beginning Domain Validation
target4:0:2: Ending Domain Validation
target4:0:2: FAST-160 WIDE SCSI 320.0 MB/s DT IU (6.25 ns, offset 127)
SCSI device sde: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sde: drive cache: write back
SCSI device sde: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sde: drive cache: write back
sde: sde1
Attached scsi disk sde at scsi4, channel 0, id 2, lun 0
Vendor: FUJITSU Model: MAS3735NP Rev: 0104
Type: Direct-Access ANSI SCSI revision: 03
target4:0:3: Beginning Domain Validation
target4:0:3: Ending Domain Validation
target4:0:3: FAST-160 WIDE SCSI 320.0 MB/s DT IU (6.25 ns, offset 127)
SCSI device sdf: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdf: drive cache: write back
SCSI device sdf: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdf: drive cache: write back
sdf: sdf1
Attached scsi disk sdf at scsi4, channel 0, id 3, lun 0
ACPI: PCI Interrupt :02:04.1[B] -> GSI 25 (level, low) -> IRQ 225
mptbase: Initiating ioc1 bringup
ioc1: 53C1030: Capabilities={Initiator,Target}
scsi5 : ioc1: LSI53C1030, FwRev=01032700h, Ports=1, MaxQ=255, IRQ=225
Vendor: FUJITSU Model: MAS3735NP Rev: 0104
Type: Direct-Access ANSI SCSI revision: 03
target5:0:0: Beginning Domain Validation
target5:0:0: Ending Domain Validation
target5:0:0: FAST-160 WIDE SCSI 320.0 MB/s DT IU (6.25 ns, offset 127)
SCSI device sdg: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdg: drive cache: write back
SCSI device sdg: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdg: drive cache:
RE: As of 2.6.13-rc1 Fusion-MPT very slow
On Sat, 2005-08-06 at 21:12 +, Holger Kiehl wrote: > I tried from 2.6.13-rc2-mm2 up to 2.6.13-rc4-mm1 and always get the following > error when applying this patch: > > CC drivers/message/fusion/mptbase.o > CC drivers/message/fusion/mptscsih.o > CC drivers/message/fusion/mptspi.o > drivers/message/fusion/mptspi.c: In function â..mptspi_target_allocâ..: > drivers/message/fusion/mptspi.c:113: error: invalid storage class for > function â..mptspi_write_offsetâ.. > drivers/message/fusion/mptspi.c:114: error: invalid storage class for > function â..mptspi_write_widthâ.. > drivers/message/fusion/mptspi.c:131: warning: implicit declaration of > function â..mptspi_write_widthâ.. > drivers/message/fusion/mptspi.c: At top level: > drivers/message/fusion/mptspi.c:453: warning: conflicting types for > â..mptspi_write_widthâ.. > drivers/message/fusion/mptspi.c:453: error: static declaration of > â..mptspi_write_widthâ.. follows non-static declaration > drivers/message/fusion/mptspi.c:131: error: previous implicit declaration > of â..mptspi_write_widthâ.. was here This lot are all gcc-4 being silly about a declaration, as you noticed. Still, there's no reason not to make the static functions declared at the top of the file. > drivers/message/fusion/mptspi.c:505: error: unknown field > â..get_hold_mcsâ.. specified in initializer > drivers/message/fusion/mptspi.c:505: warning: excess elements in struct > initializer > drivers/message/fusion/mptspi.c:505: warning: (near initialization for > â..mptspi_transport_functionsâ..) > drivers/message/fusion/mptspi.c:506: error: unknown field > â..set_hold_mcsâ.. specified in initializer > drivers/message/fusion/mptspi.c:506: warning: excess elements in struct > initializer > drivers/message/fusion/mptspi.c:506: warning: (near initialization for > â..mptspi_transport_functionsâ..) > drivers/message/fusion/mptspi.c:507: error: unknown field > â..show_hold_mcsâ.. specified in initializer > drivers/message/fusion/mptspi.c:507: warning: excess elements in struct > initializer > drivers/message/fusion/mptspi.c:507: warning: (near initialization for > â..mptspi_transport_functionsâ..) This is actually because -mm is slightly behind the scsi-misc tree. It looks like the hold_mcs parameters haven't propagated into the -mm tree yet. You should be able to correct this by cutting these three lines: .get_hold_mcs = mptspi_read_parameters, .set_hold_mcs = mptspi_write_hold_mcs, .show_hold_mcs = 1, Out of the code at lines 505-507. You'll get a warning about mptspi_write_hold_mcs() being defined but not used which you can ignore. James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: As of 2.6.13-rc1 Fusion-MPT very slow
On Sat, 6 Aug 2005, James Bottomley wrote: On Mon, 2005-08-01 at 15:40 +, Holger Kiehl wrote: No I did not get it. Can you please send it to me or tell me where I can download it? OK, since this has stalled, how about trying a different approach. If you apply the attached patch it will cause fusion to use the transport class domain validation. That should show us which parameters are causing the problem and exactly what the negotiations said. We can also tell you how to tweak the parameters. It should apply to any recent -mm (unless Andrew does a turn to pick up the fusion module rework). I tried from 2.6.13-rc2-mm2 up to 2.6.13-rc4-mm1 and always get the following error when applying this patch: CC drivers/message/fusion/mptbase.o CC drivers/message/fusion/mptscsih.o CC drivers/message/fusion/mptspi.o drivers/message/fusion/mptspi.c: In function â..mptspi_target_allocâ..: drivers/message/fusion/mptspi.c:113: error: invalid storage class for function â..mptspi_write_offsetâ.. drivers/message/fusion/mptspi.c:114: error: invalid storage class for function â..mptspi_write_widthâ.. drivers/message/fusion/mptspi.c:131: warning: implicit declaration of function â..mptspi_write_widthâ.. drivers/message/fusion/mptspi.c: At top level: drivers/message/fusion/mptspi.c:453: warning: conflicting types for â..mptspi_write_widthâ.. drivers/message/fusion/mptspi.c:453: error: static declaration of â..mptspi_write_widthâ.. follows non-static declaration drivers/message/fusion/mptspi.c:131: error: previous implicit declaration of â..mptspi_write_widthâ.. was here drivers/message/fusion/mptspi.c:505: error: unknown field â..get_hold_mcsâ.. specified in initializer drivers/message/fusion/mptspi.c:505: warning: excess elements in struct initializer drivers/message/fusion/mptspi.c:505: warning: (near initialization for â..mptspi_transport_functionsâ..) drivers/message/fusion/mptspi.c:506: error: unknown field â..set_hold_mcsâ.. specified in initializer drivers/message/fusion/mptspi.c:506: warning: excess elements in struct initializer drivers/message/fusion/mptspi.c:506: warning: (near initialization for â..mptspi_transport_functionsâ..) drivers/message/fusion/mptspi.c:507: error: unknown field â..show_hold_mcsâ.. specified in initializer drivers/message/fusion/mptspi.c:507: warning: excess elements in struct initializer drivers/message/fusion/mptspi.c:507: warning: (near initialization for â..mptspi_transport_functionsâ..) make[3]: *** [drivers/message/fusion/mptspi.o] Error 1 make[2]: *** [drivers/message/fusion] Error 2 make[1]: *** [drivers/message] Error 2 make: *** [drivers] Error 2 The first errors I was able to resolve by placing the function prototype definitions (line 113 and 114) outside the function. I am using gcc 4.0.1. But the errors in line 505 onwards I don't know what to do. Should I take an earlier -mm release? Thanks, Holger
RE: As of 2.6.13-rc1 Fusion-MPT very slow
On Mon, 2005-08-01 at 15:40 +, Holger Kiehl wrote:
> No I did not get it. Can you please send it to me or tell me where I can
> download it?
OK, since this has stalled, how about trying a different approach.
If you apply the attached patch it will cause fusion to use the
transport class domain validation. That should show us which parameters
are causing the problem and exactly what the negotiations said. We can
also tell you how to tweak the parameters.
It should apply to any recent -mm (unless Andrew does a turn to pick up
the fusion module rework).
Thanks,
James
diff --git a/drivers/message/fusion/Kconfig b/drivers/message/fusion/Kconfig
--- a/drivers/message/fusion/Kconfig
+++ b/drivers/message/fusion/Kconfig
@@ -9,6 +9,7 @@ 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.
diff --git a/drivers/message/fusion/mptscsih.c
b/drivers/message/fusion/mptscsih.c
--- a/drivers/message/fusion/mptscsih.c
+++ b/drivers/message/fusion/mptscsih.c
@@ -149,8 +149,6 @@ int mptscsih_ioc_reset(MPT_ADAPTER *ioc
intmptscsih_event_process(MPT_ADAPTER *ioc,
EventNotificationReply_t *pEvReply);
static voidmptscsih_initTarget(MPT_SCSI_HOST *hd, int bus_id, int
target_id, u8 lun, char *data, int dlen);
-static voidmptscsih_setTargetNegoParms(MPT_SCSI_HOST *hd, VirtDevice
*target, char byte56);
-static voidmptscsih_set_dvflags(MPT_SCSI_HOST *hd, SCSIIORequest_t *pReq);
static voidmptscsih_setDevicePage1Flags (u8 width, u8 factor, u8 offset,
int *requestedPtr, int *configurationPtr, u8 flags);
static voidmptscsih_no_negotiate(MPT_SCSI_HOST *hd, int target_id);
static int mptscsih_writeSDP1(MPT_SCSI_HOST *hd, int portnum, int target,
int flags);
@@ -955,8 +953,6 @@ mptscsih_remove(struct pci_dev *pdev)
MPT_ADAPTER *ioc = pci_get_drvdata(pdev);
struct Scsi_Host*host = ioc->sh;
MPT_SCSI_HOST *hd;
- int count;
- unsigned long flags;
int sz1;
if(!host)
@@ -2502,7 +2498,7 @@ mptscsih_ioc_reset(MPT_ADAPTER *ioc, int
/* 4. Renegotiate to all devices, if SCSI
*/
if (ioc->bus_type == SCSI) {
- dnegoprintk(("writeSDP1: ALL_IDS USE_NVRAM\n"));
+ printk("writeSDP1: ALL_IDS USE_NVRAM\n");
mptscsih_writeSDP1(hd, 0, 0, MPT_SCSICFG_ALL_IDS |
MPT_SCSICFG_USE_NVRAM);
}
@@ -2761,7 +2757,6 @@ mptscsih_initTarget(MPT_SCSI_HOST *hd, i
vdev->tflags |=
MPT_TARGET_FLAGS_VALID_56;
}
}
- mptscsih_setTargetNegoParms(hd, vdev, data_56);
} else {
/* Initial Inquiry may not request enough data bytes to
* obtain byte 57. DV will; if target doesn't return
@@ -2772,7 +2767,6 @@ mptscsih_initTarget(MPT_SCSI_HOST *hd, i
*/
data_56 = data[56];
vdev->tflags |=
MPT_TARGET_FLAGS_VALID_56;
- mptscsih_setTargetNegoParms(hd, vdev,
data_56);
}
}
}
@@ -2781,225 +2775,6 @@ mptscsih_initTarget(MPT_SCSI_HOST *hd, i
/*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
/*
- * Update the target negotiation parameters based on the
- * the Inquiry data, adapter capabilities, and NVRAM settings.
- *
- */
-static void
-mptscsih_setTargetNegoParms(MPT_SCSI_HOST *hd, VirtDevice *target, char byte56)
-{
- ScsiCfgData *pspi_data = &hd->ioc->spi_data;
- int id = (int) target->target_id;
- int nvram;
- VirtDevice *vdev;
- int ii;
- u8 width = MPT_NARROW;
- u8 factor = MPT_ASYNC;
- u8 offset = 0;
- u8 version, nfactor;
- u8 noQas = 1;
-
- target->negoFlags = pspi_data->noQas;
-
- /* noQas == 0 => device supports QAS. Need byte 56 of Inq to determine
-* support. If available, default QAS to off and allow enabling.
-* If not available, default QAS to on, turn off for non-disks.
-*/
-
- /* Set flags based on Inquiry data
-*/
- version = target->inq_data[2] & 0x07;
- if (version < 2) {
- width = 0;
- factor = MPT_ULTRA2;
- offset = pspi_data->maxSyncOffset;
- target->tflags &= ~MPT_TARGET_FLAGS_Q_YES;
- } else {
- if (target->inq_data[7] & 0x20) {
- width = 1;
- }
-
- if (target->inq_data[7] & 0x10) {
-
RE: As of 2.6.13-rc1 Fusion-MPT very slow
No I did not get it. Can you please send it to me or tell me where I can
download it?
Thanks,
Holger
--
On Mon, 1 Aug 2005, Moore, Eric Dean wrote:
I provided an application called getspeed as an attachment
in the email I sent last Friday. Did you receive that, or do
I need to resend? If possible, can run that application
and send me the output.
Regards,
Eric Moore
On Monday, August 01, 2005 4:16 AM, Holger Kiehl wrote:
On Fri, 29 Jul 2005, Andrew Morton wrote:
"Moore, Eric Dean" <[EMAIL PROTECTED]> wrote:
Regarding the 1st issue, can you try this patch out. It
maybe in the
-mm branch. Andrew cc'd on this email can confirm.
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/
2.6.13-rc3/2.6
.13-rc3-mm3/broken-out/mpt-fusion-dv-fixes.patch
Yes, that's part of 2.6.13-rc3-mm3.
The patch makes no difference. Still get the following
results when fusion
is compiled in:
sdc 74MB/s
sdd2MB/s
sde2MB/s
sdf2MB/s
On second channel:
sdg 74MB/s
sdh 74MB/s
sdi 74MB/s
sdj 74MB/s
The patch was applied to linux-2.6.13-rc4-git3.
Here part of dmesg output:
Fusion MPT base driver 3.03.02
Copyright (c) 1999-2005 LSI Logic Corporation
Fusion MPT SPI Host driver 3.03.02
ACPI: PCI Interrupt :02:04.0[A] -> GSI 24 (level,
low) -> IRQ 217
mptbase: Initiating ioc0 bringup
ioc0: 53C1030: Capabilities={Initiator,Target}
scsi4 : ioc0: LSI53C1030, FwRev=01032700h, Ports=1,
MaxQ=255, IRQ=217
Vendor: FUJITSU Model: MAS3735NP Rev: 0104
Type: Direct-Access ANSI SCSI
revision: 03
SCSI device sdc: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdc: drive cache: write back
SCSI device sdc: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdc: drive cache: write back
sdc: sdc1
Attached scsi disk sdc at scsi4, channel 0, id 0, lun 0
Vendor: FUJITSU Model: MAS3735NP Rev: 0104
Type: Direct-Access ANSI SCSI
revision: 03
SCSI device sdd: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdd: drive cache: write back
SCSI device sdd: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdd: drive cache: write back
sdd: sdd1
Attached scsi disk sdd at scsi4, channel 0, id 1, lun 0
Vendor: FUJITSU Model: MAS3735NP Rev: 0104
Type: Direct-Access ANSI SCSI
revision: 03
SCSI device sde: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sde: drive cache: write back
SCSI device sde: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sde: drive cache: write back
sde: sde1
Attached scsi disk sde at scsi4, channel 0, id 2, lun 0
Vendor: FUJITSU Model: MAS3735NP Rev: 0104
Type: Direct-Access ANSI SCSI
revision: 03
SCSI device sdf: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdf: drive cache: write back
SCSI device sdf: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdf: drive cache: write back
sdf: sdf1
Attached scsi disk sdf at scsi4, channel 0, id 3, lun 0
ACPI: PCI Interrupt :02:04.1[B] -> GSI 25 (level,
low) -> IRQ 225
mptbase: Initiating ioc1 bringup
ioc1: 53C1030: Capabilities={Initiator,Target}
scsi5 : ioc1: LSI53C1030, FwRev=01032700h, Ports=1,
MaxQ=255, IRQ=225
Vendor: FUJITSU Model: MAS3735NP Rev: 0104
Type: Direct-Access ANSI SCSI
revision: 03
SCSI device sdg: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdg: drive cache: write back
SCSI device sdg: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdg: drive cache: write back
sdg: sdg1
Attached scsi disk sdg at scsi5, channel 0, id 0, lun 0
Vendor: FUJITSU Model: MAS3735NP Rev: 0104
Type: Direct-Access ANSI SCSI
revision: 03
SCSI device sdh: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdh: drive cache: write back
SCSI device sdh: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdh: drive cache: write back
sdh: sdh1
Attached scsi disk sdh at scsi5, channel 0, id 1, lun 0
Vendor: FUJITSU Model: MAS3735NP Rev: 0104
Type: Direct-Access ANSI SCSI
revision: 03
SCSI device sdi: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdi: drive cache: write back
SCSI device sdi: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdi: drive cache: write back
sdi: sdi1
Attached scsi disk sdi at scsi5, channel 0, id 2, lun 0
Vendor: FUJITSU Model: MAS3735NP Rev: 0104
Type: Direct-Access ANSI SCSI
revision: 03
SCSI device sdj: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdj: drive cache: write back
SCSI device sdj:
RE: As of 2.6.13-rc1 Fusion-MPT very slow
I provided an application called getspeed as an attachment
in the email I sent last Friday. Did you receive that, or do
I need to resend? If possible, can run that application
and send me the output.
Regards,
Eric Moore
On Monday, August 01, 2005 4:16 AM, Holger Kiehl wrote:
> On Fri, 29 Jul 2005, Andrew Morton wrote:
>
> > "Moore, Eric Dean" <[EMAIL PROTECTED]> wrote:
> >>
> >> Regarding the 1st issue, can you try this patch out. It
> maybe in the
> >> -mm branch. Andrew cc'd on this email can confirm.
> >>
> >>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/
> 2.6.13-rc3/2.6
> >> .13-rc3-mm3/broken-out/mpt-fusion-dv-fixes.patch
> >
> > Yes, that's part of 2.6.13-rc3-mm3.
> >
> The patch makes no difference. Still get the following
> results when fusion
> is compiled in:
>
>sdc 74MB/s
>sdd2MB/s
>sde2MB/s
>sdf2MB/s
>
> On second channel:
>
>sdg 74MB/s
>sdh 74MB/s
>sdi 74MB/s
>sdj 74MB/s
>
> The patch was applied to linux-2.6.13-rc4-git3.
>
> Here part of dmesg output:
>
> Fusion MPT base driver 3.03.02
> Copyright (c) 1999-2005 LSI Logic Corporation
> Fusion MPT SPI Host driver 3.03.02
> ACPI: PCI Interrupt :02:04.0[A] -> GSI 24 (level,
> low) -> IRQ 217
> mptbase: Initiating ioc0 bringup
> ioc0: 53C1030: Capabilities={Initiator,Target}
> scsi4 : ioc0: LSI53C1030, FwRev=01032700h, Ports=1,
> MaxQ=255, IRQ=217
> Vendor: FUJITSU Model: MAS3735NP Rev: 0104
> Type: Direct-Access ANSI SCSI
> revision: 03
> SCSI device sdc: 143552136 512-byte hdwr sectors (73499 MB)
> SCSI device sdc: drive cache: write back
> SCSI device sdc: 143552136 512-byte hdwr sectors (73499 MB)
> SCSI device sdc: drive cache: write back
> sdc: sdc1
> Attached scsi disk sdc at scsi4, channel 0, id 0, lun 0
> Vendor: FUJITSU Model: MAS3735NP Rev: 0104
> Type: Direct-Access ANSI SCSI
> revision: 03
> SCSI device sdd: 143552136 512-byte hdwr sectors (73499 MB)
> SCSI device sdd: drive cache: write back
> SCSI device sdd: 143552136 512-byte hdwr sectors (73499 MB)
> SCSI device sdd: drive cache: write back
> sdd: sdd1
> Attached scsi disk sdd at scsi4, channel 0, id 1, lun 0
> Vendor: FUJITSU Model: MAS3735NP Rev: 0104
> Type: Direct-Access ANSI SCSI
> revision: 03
> SCSI device sde: 143552136 512-byte hdwr sectors (73499 MB)
> SCSI device sde: drive cache: write back
> SCSI device sde: 143552136 512-byte hdwr sectors (73499 MB)
> SCSI device sde: drive cache: write back
> sde: sde1
> Attached scsi disk sde at scsi4, channel 0, id 2, lun 0
> Vendor: FUJITSU Model: MAS3735NP Rev: 0104
> Type: Direct-Access ANSI SCSI
> revision: 03
> SCSI device sdf: 143552136 512-byte hdwr sectors (73499 MB)
> SCSI device sdf: drive cache: write back
> SCSI device sdf: 143552136 512-byte hdwr sectors (73499 MB)
> SCSI device sdf: drive cache: write back
> sdf: sdf1
> Attached scsi disk sdf at scsi4, channel 0, id 3, lun 0
> ACPI: PCI Interrupt :02:04.1[B] -> GSI 25 (level,
> low) -> IRQ 225
> mptbase: Initiating ioc1 bringup
> ioc1: 53C1030: Capabilities={Initiator,Target}
> scsi5 : ioc1: LSI53C1030, FwRev=01032700h, Ports=1,
> MaxQ=255, IRQ=225
> Vendor: FUJITSU Model: MAS3735NP Rev: 0104
> Type: Direct-Access ANSI SCSI
> revision: 03
> SCSI device sdg: 143552136 512-byte hdwr sectors (73499 MB)
> SCSI device sdg: drive cache: write back
> SCSI device sdg: 143552136 512-byte hdwr sectors (73499 MB)
> SCSI device sdg: drive cache: write back
> sdg: sdg1
> Attached scsi disk sdg at scsi5, channel 0, id 0, lun 0
> Vendor: FUJITSU Model: MAS3735NP Rev: 0104
> Type: Direct-Access ANSI SCSI
> revision: 03
> SCSI device sdh: 143552136 512-byte hdwr sectors (73499 MB)
> SCSI device sdh: drive cache: write back
> SCSI device sdh: 143552136 512-byte hdwr sectors (73499 MB)
> SCSI device sdh: drive cache: write back
> sdh: sdh1
> Attached scsi disk sdh at scsi5, channel 0, id 1, lun 0
> Vendor: FUJITSU Model: MAS3735NP Rev: 0104
> Type: Direct-Access ANSI SCSI
> revision: 03
> SCSI device sdi: 143552136 512-byte hdwr sectors (73499 MB)
> SCSI device sdi: drive cache: write back
> SCSI device sdi: 143552136 512-byte hdwr sectors (73499 MB)
> SCSI device sdi: drive cache: write back
> sdi: sdi1
> Attached scsi disk sdi at scsi5, channel 0, id 2, lun 0
> Vendor: FUJITSU Model: MAS3735NP Rev: 0104
> Type: Direct-Access ANSI SCSI
> revision: 03
> SCSI device sdj
Re: As of 2.6.13-rc1 Fusion-MPT very slow
On Fri, 29 Jul 2005, Andrew Morton wrote:
"Moore, Eric Dean" <[EMAIL PROTECTED]> wrote:
Regarding the 1st issue, can you try this patch out. It maybe in the
-mm branch. Andrew cc'd on this email can confirm.
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6
.13-rc3-mm3/broken-out/mpt-fusion-dv-fixes.patch
Yes, that's part of 2.6.13-rc3-mm3.
The patch makes no difference. Still get the following results when fusion
is compiled in:
sdc 74MB/s
sdd2MB/s
sde2MB/s
sdf2MB/s
On second channel:
sdg 74MB/s
sdh 74MB/s
sdi 74MB/s
sdj 74MB/s
The patch was applied to linux-2.6.13-rc4-git3.
Here part of dmesg output:
Fusion MPT base driver 3.03.02
Copyright (c) 1999-2005 LSI Logic Corporation
Fusion MPT SPI Host driver 3.03.02
ACPI: PCI Interrupt :02:04.0[A] -> GSI 24 (level, low) -> IRQ 217
mptbase: Initiating ioc0 bringup
ioc0: 53C1030: Capabilities={Initiator,Target}
scsi4 : ioc0: LSI53C1030, FwRev=01032700h, Ports=1, MaxQ=255, IRQ=217
Vendor: FUJITSU Model: MAS3735NP Rev: 0104
Type: Direct-Access ANSI SCSI revision: 03
SCSI device sdc: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdc: drive cache: write back
SCSI device sdc: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdc: drive cache: write back
sdc: sdc1
Attached scsi disk sdc at scsi4, channel 0, id 0, lun 0
Vendor: FUJITSU Model: MAS3735NP Rev: 0104
Type: Direct-Access ANSI SCSI revision: 03
SCSI device sdd: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdd: drive cache: write back
SCSI device sdd: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdd: drive cache: write back
sdd: sdd1
Attached scsi disk sdd at scsi4, channel 0, id 1, lun 0
Vendor: FUJITSU Model: MAS3735NP Rev: 0104
Type: Direct-Access ANSI SCSI revision: 03
SCSI device sde: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sde: drive cache: write back
SCSI device sde: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sde: drive cache: write back
sde: sde1
Attached scsi disk sde at scsi4, channel 0, id 2, lun 0
Vendor: FUJITSU Model: MAS3735NP Rev: 0104
Type: Direct-Access ANSI SCSI revision: 03
SCSI device sdf: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdf: drive cache: write back
SCSI device sdf: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdf: drive cache: write back
sdf: sdf1
Attached scsi disk sdf at scsi4, channel 0, id 3, lun 0
ACPI: PCI Interrupt :02:04.1[B] -> GSI 25 (level, low) -> IRQ 225
mptbase: Initiating ioc1 bringup
ioc1: 53C1030: Capabilities={Initiator,Target}
scsi5 : ioc1: LSI53C1030, FwRev=01032700h, Ports=1, MaxQ=255, IRQ=225
Vendor: FUJITSU Model: MAS3735NP Rev: 0104
Type: Direct-Access ANSI SCSI revision: 03
SCSI device sdg: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdg: drive cache: write back
SCSI device sdg: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdg: drive cache: write back
sdg: sdg1
Attached scsi disk sdg at scsi5, channel 0, id 0, lun 0
Vendor: FUJITSU Model: MAS3735NP Rev: 0104
Type: Direct-Access ANSI SCSI revision: 03
SCSI device sdh: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdh: drive cache: write back
SCSI device sdh: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdh: drive cache: write back
sdh: sdh1
Attached scsi disk sdh at scsi5, channel 0, id 1, lun 0
Vendor: FUJITSU Model: MAS3735NP Rev: 0104
Type: Direct-Access ANSI SCSI revision: 03
SCSI device sdi: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdi: drive cache: write back
SCSI device sdi: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdi: drive cache: write back
sdi: sdi1
Attached scsi disk sdi at scsi5, channel 0, id 2, lun 0
Vendor: FUJITSU Model: MAS3735NP Rev: 0104
Type: Direct-Access ANSI SCSI revision: 03
SCSI device sdj: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdj: drive cache: write back
SCSI device sdj: 143552136 512-byte hdwr sectors (73499 MB)
SCSI device sdj: drive cache: write back
sdj: sdj1
Attached scsi disk sdj at scsi5, channel 0, id 3, lun 0
Anything else I can try or provide?
Holger
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: As of 2.6.13-rc1 Fusion-MPT very slow
"Moore, Eric Dean" <[EMAIL PROTECTED]> wrote: > > Regarding the 1st issue, can you try this patch out. It maybe in the > -mm branch. Andrew cc'd on this email can confirm. > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6 > .13-rc3-mm3/broken-out/mpt-fusion-dv-fixes.patch Yes, that's part of 2.6.13-rc3-mm3. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
As of 2.6.13-rc1 Fusion-MPT very slow
Hello On a four CPU Opteron with Fusion-MPT compiled in, I get the following results (up to 2.6.13-rc3-git7) with hdparm on the first channel with four disks: sdc74 MB/s sdd 2 MB/s sde 2 MB/s sdf 2 MB/s On the second channel also with the same type of disks: sdg74 MB/s sdh74 MB/s sdi74 MB/s sdj74 MB/s All disk are of the same type. Compiling Fusion-MPT as module for the same kernel I get 74 MB/s for all eight disks. Taking kernel 2.6.12.2 and compile it in, all eigth disks give the expected performance of 74 MB/s. When I exchange the two cables, put the first cable on second channel and second cable on first channel, always sdd, sde and sdf will only get approx. 2 MB/s with any 2.6.13-* kernels. Another problem observed with 2.6.13-rc3-git7 and Fusion-MPT compiled in is when making a ext3 filesystem over those eight disks (software Raid10), makes mke2fs hang for a very long time in D-state and /var/log/messages writting a lot of these messages: mptscsih: ioc0: >> Attempting task abort! (sc=81014ead3ac0) mptscsih: ioc0: >> Attempting task abort! (sc=81014ead38c0) mptscsih: ioc0: >> Attempting task abort! (sc=81014ead36c0) mptscsih: ioc0: >> Attempting task abort! (sc=81014ead34c0) . . . And finally, when I do a halt or powerdown just after all filesystems are unmounted the fusion driver tells me that it puts the two controllers in power save mode. Then kernel whants to flush the SCSI disks but hangs forever. This does not happen when doing a reboot. Holger -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
