Re: SCSI breakage on PowerMac 9500 (oldworld) between 2.6.19.7 and 2.6.20
On Wed, 11 Apr 2007 03:08:50 +0200 Martin Geier wrote: > Hi > > On Tue, Apr 10, 2007 at 03:53:59PM -0700, Randy Dunlap wrote: > > On Wed, 11 Apr 2007 00:12:17 +0200 Martin Geier wrote: > (..) > > > Maybe it's connected to > > > http://marc.info/?l=linux-scsi&m=117596425706527&w=2 > > > but my test of 2.6.21-rc5 failed similarly to the test of 2.6.20. > (..) > > There was a similar report for the imm driver, with a follow-up > > report that 2.6.21-rc5 works. Could you test 2.6.21-rc6? > I think I saw that one (in case you mean the one mentioned above). > rc5 (*) didn't work, but fortunately rc6 does work. Do you have any > idea which commit fixed this (and if I can apply it against 2.6.20.6)? No, sorry, I don't know what patch fixes it. I just know that I can reproduce the failure + fix using the imm driver. > Martin > > *) > http://www.de.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.21-rc5.tar.bz2 > vs. > http://www.de.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.21-rc6.tar.bz2 --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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: SCSI breakage on PowerMac 9500 (oldworld) between 2.6.19.7 and 2.6.20
Hi On Tue, Apr 10, 2007 at 03:53:59PM -0700, Randy Dunlap wrote: > On Wed, 11 Apr 2007 00:12:17 +0200 Martin Geier wrote: (..) > > Maybe it's connected to http://marc.info/?l=linux-scsi&m=117596425706527&w=2 > > but my test of 2.6.21-rc5 failed similarly to the test of 2.6.20. (..) > There was a similar report for the imm driver, with a follow-up > report that 2.6.21-rc5 works. Could you test 2.6.21-rc6? I think I saw that one (in case you mean the one mentioned above). rc5 (*) didn't work, but fortunately rc6 does work. Do you have any idea which commit fixed this (and if I can apply it against 2.6.20.6)? Martin *) http://www.de.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.21-rc5.tar.bz2 vs. http://www.de.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.21-rc6.tar.bz2 -- /¯¯¯\ | PGP-Key 0x0F10B493 available via www.de.pgp.net, see header for fpr | \___/ - 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 4/5] Do an agent reset on error recovery.
I wrote: > Kristian Høgsberg wrote: >> Also, implement the .eh_host_reset_handler callback instead of >> .eh_abort_handler since that's what we're actually doing. > > You reset the target port (or specifically, the fetch agent acting on > that target port). But the .eh_host_reset_handler is to "ask [the] host > adapter to reset itself". ... > But theoretic semantics aside: Check drivers/scsi/scsi_error.c for what > comes after one or another hostt->eh_ handler was called. Do you want > the subsequent call to scsi_report_bus_reset()? Probably not. But > perhaps you want what comes after hostt->eh_device_reset_handler was called. BTW, as you probably know there are different ways to (try to) bring an SBP-2 target back to reason. A while ago someone posted an extended abort/reset scheme but I still haven't looked into it in detail and tested it for its practical effects. http://me.in-berlin.de/~s5r6/linux1394/work-in-progress/sbp2-scsi-abort-and-reset-of-non-responding-devices.patch -- Stefan Richter -=-=-=== -=-- -=-== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: difference between arcmsr (areca) 1.20.0X.13 & 2.6.20 in tree driver?
The RAID card in question has reported an "SPD CheckSum Error" (bad ram?) during system power on so it's looking like this is probably a hardware or firmware problem and not a driver issue. -J -- On Tue, Apr 03, 2007 at 08:45:38AM -0700, Randy Dunlap wrote: > On Mon, 2 Apr 2007 17:21:35 -1000 Joshua Hoblitt wrote: > > [adding linux-scsi] > > > Has anyone else noticed this regression? > > > > -J > > > > -- > > - Forwarded message from Joshua Hoblitt <[EMAIL PROTECTED]> - > > > > From: Joshua Hoblitt <[EMAIL PROTECTED]> > > Date: Thu, 29 Mar 2007 16:38:20 -1000 > > To: [EMAIL PROTECTED] > > Subject: difference between 1.20.0X.13 & 2.6.20 in tree driver? > > > > Hello, > > > > I just attempted to upgrade a system from 2.6.17 (gentoo revision 8) w/ > > 1.20.0X.13 to 2.6.20 (gentoo revision 4) with the in tree arcmsr driver. > > On the 2.6.17 kernel there are 2 ~4TB partitions that are visible on > > the system as /dev/sdb1 & /dev/sdc1. When the system is booted with the > > 2.6.20 kernel /dev/sdc1 is gone and /dev/sdb1 is properly reported as a > > 4TB EFI partition but fsck rejects the the filesystem as corrupt. Is > > this a regression or has there been a fundamental change in the way > > arcmsr represents the array to the block layer? > > > > Here is the info on the RAID card: > > > > Controller Name ARC-1170 > > Firmware VersionV1.39 2005-12-13 > > BOOT ROM VersionV1.39 2005-12-13 > > Serial Number Y605CAAVAR700117 > > Unit Serial # > > Main Processor 500MHz IOP331 > > CPU ICache Size 32KBytes > > CPU DCache Size 32KBytes / Write Back > > System Memory 256MB / 333MHz > > > > Any idea as to what's going on? > > > > Thanks, > > > > -J > > > > -- > > Under 2.6.20: > > > > Mar 29 15:41:05 ipp000 ARECA RAID ADAPTER4: FIRMWARE VERSION V1.39 > > 2005-12-13 > > Mar 29 15:41:05 ipp000 scsi4 : Areca SATA Host Adapter RAID Controller( > > RAID6 capable) > > Mar 29 15:41:05 ipp000 Driver Version 1.20.00.13 > > Mar 29 15:41:05 ipp000 scsi 4:0:0:0: Direct-Access Areca > > ARC-1170-VOL#00 R001 PQ: 0 ANSI: 3 > > Mar 29 15:41:05 ipp000 sdb : very big device. try to use READ CAPACITY(16). > > Mar 29 15:41:05 ipp000 SCSI device sdb: 8595693568 512-byte hdwr sectors > > (4400995 MB) > > Mar 29 15:41:05 ipp000 sdb: Write Protect is off > > Mar 29 15:41:05 ipp000 sdb: Mode Sense: cb 00 00 08 > > Mar 29 15:41:05 ipp000 SCSI device sdb: write cache: enabled, read cache: > > enabled, doesn't support DPO or FUA > > Mar 29 15:41:05 ipp000 sdb : very big device. try to use READ CAPACITY(16). > > Mar 29 15:41:05 ipp000 SCSI device sdb: 8595693568 512-byte hdwr sectors > > (4400995 MB) > > Mar 29 15:41:05 ipp000 sdb: Write Protect is off > > Mar 29 15:41:05 ipp000 sdb: Mode Sense: cb 00 00 08 > > Mar 29 15:41:05 ipp000 SCSI device sdb: write cache: enabled, read cache: > > enabled, doesn't support DPO or FUA > > Mar 29 15:41:05 ipp000 sdb: sdb1 > > Mar 29 15:41:05 ipp000 sd 4:0:0:0: Attached scsi disk sdb > > Mar 29 15:41:05 ipp000 scsi 4:0:16:0: Processor ArecaRAID > > controller R001 PQ: 0 ANSI: 0 > > > > Under 2.6.17: > > > > Mar 29 15:45:11 ipp000 ARECA RAID ADAPTER0: 64BITS PCI BUS DMA ADDRESSING > > SUPPORTED > > Mar 29 15:45:11 ipp000 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.39 > > 2005-12-13 > > Mar 29 15:45:11 ipp000 scsi4 : Areca SATA Host Adapter RAID Controller( > > RAID6 capable) > > Mar 29 15:45:11 ipp000 Driver Version 1.20.0X.13 > > Mar 29 15:45:11 ipp000 Vendor: Areca Model: ARC-1170-VOL#00 Rev: R001 > > Mar 29 15:45:11 ipp000 Type: Direct-Access ANSI SCSI > > revision: 03 > > Mar 29 15:45:11 ipp000 sdb : very big device. try to use READ CAPACITY(16). > > Mar 29 15:45:11 ipp000 SCSI device sdb: 8595693568 512-byte hdwr sectors > > (4400995 MB) > > Mar 29 15:45:11 ipp000 sdb: Write Protect is off > > Mar 29 15:45:11 ipp000 sdb: Mode Sense: cb 00 00 08 > > Mar 29 15:45:11 ipp000 SCSI device sdb: drive cache: write back > > Mar 29 15:45:11 ipp000 sdb : very big device. try to use READ CAPACITY(16). > > Mar 29 15:45:11 ipp000 SCSI device sdb: 8595693568 512-byte hdwr sectors > > (4400995 MB) > > Mar 29 15:45:11 ipp000 sdb: Write Protect is off > > Mar 29 15:45:11 ipp000 sdb: Mode Sense: cb 00 00 08 > > Mar 29 15:45:11 ipp000 SCSI device sdb: drive cache: write back > > Mar 29 15:45:11 ipp000 sdb:<4>Alternate GPT is invalid, using primary GPT. > > Mar 29 15:45:11 ipp000 sdb1 > > Mar 29 15:45:11 ipp000 sd 4:0:0:0: Attached scsi disk sdb > > Mar 29 15:45:11 ipp000 sd 4:0:0:0: Attached scsi generic sg1 type 0 > > Mar 29 15:45:11 ipp000 Vendor: Areca Model: ARC-1170-VOL#01 Rev: R001 > > Mar 29 15:45:11 ipp000 Type: Direct-Access ANSI SCSI > > revision: 03 > > Mar 29 15:45:11 ipp000 sdc : very big device. try to use READ CAPACITY(16). > > Mar 29 15:45:11 ipp000 SCSI device sdc: 8595580928 512-byte hdwr sectors > > (4400937 MB) > > Mar 29 15:
Re: [PATCH 4/5] Do an agent reset on error recovery.
(added Cc: LSML)
Kristian Høgsberg wrote:
> Also, implement the .eh_host_reset_handler callback instead of
> .eh_abort_handler since that's what we're actually doing.
You reset the target port (or specifically, the fetch agent acting on
that target port). But the .eh_host_reset_handler is to "ask [the] host
adapter to reset itself". Or in the words of scsi_mid_low_api.txt:
eh_abort_handler - abort given command
eh_bus_reset_handler - issue SCSI bus reset
eh_device_reset_handler - issue SCSI device reset
eh_host_reset_handler - reset host (host bus adapter)
The closest concept to "host bus adpaters" in SBP-2 are initiator ports,
and there is no notion of resetting an SBP-2 initiator port.
But theoretic semantics aside: Check drivers/scsi/scsi_error.c for what
comes after one or another hostt->eh_ handler was called. Do you want
the subsequent call to scsi_report_bus_reset()? Probably not. But
perhaps you want what comes after hostt->eh_device_reset_handler was called.
> Signed-off-by: Kristian Høgsberg <[EMAIL PROTECTED]>
> ---
> drivers/firewire/fw-sbp2.c |9 +
> 1 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/firewire/fw-sbp2.c b/drivers/firewire/fw-sbp2.c
> index a752523..c768834 100644
> --- a/drivers/firewire/fw-sbp2.c
> +++ b/drivers/firewire/fw-sbp2.c
> @@ -1068,12 +1068,13 @@ static int sbp2_scsi_slave_configure(struct
> scsi_device *sdev)
> * Called by scsi stack when something has really gone wrong. Usually
> * called when a command has timed-out for some reason.
> */
> -static int sbp2_scsi_abort(struct scsi_cmnd *cmd)
> +static int sbp2_scsi_host_reset_handler(struct scsi_cmnd *cmd)
> {
> - struct fw_unit *unit = (struct fw_unit *)cmd->device->host->hostdata[0];
> + struct fw_unit *unit =
> + (struct fw_unit *) cmd->device->host->hostdata[0];
>
> fw_notify("sbp2_scsi_abort\n");
> -
> + sbp2_agent_reset(unit);
> sbp2_cancel_orbs(unit);
>
> return SUCCESS;
> @@ -1086,7 +1087,7 @@ static struct scsi_host_template scsi_driver_template =
> {
> .queuecommand = sbp2_scsi_queuecommand,
> .slave_alloc= sbp2_scsi_slave_alloc,
> .slave_configure= sbp2_scsi_slave_configure,
> - .eh_abort_handler = sbp2_scsi_abort,
> + .eh_host_reset_handler = sbp2_scsi_host_reset_handler,
> .this_id= -1,
> .sg_tablesize = SG_ALL,
> .use_clustering = ENABLE_CLUSTERING,
--
Stefan Richter
-=-=-=== -=-- -=-==
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SCSI breakage on PowerMac 9500 (oldworld) between 2.6.19.7 and 2.6.20
On Wed, 11 Apr 2007 00:12:17 +0200 Martin Geier wrote: > Hi, > > it seems SCSI got broken somewhere on the way from 2.6.19.7 to 2.6.20 on > oldworld Apple PowerMacs 9500 using the internal mesh-controller. The > kernel fails to read the partition table from the drive(s) with the > following messages: > | mesh_host_reset > | mesh: target 0 synchronous at 10.0 MB/s > | sd 0:0:0:0: scsi: Device offlined - not ready after error recovery > | sd 0:0:0:0: rejecting I/O to offline device > | sd 0:0:0:0: rejecting I/O to offline device > | sd 0:0:0:0: rejecting I/O to offline device > | sd 0:0:0:0: rejecting I/O to offline device > | sda : READ CAPACITY failed. > | sda : status=0, message=00, host=1, driver=00 > | sda : sense not available. > | sd 0:0:0:0: rejecting I/O to offline device > | sda: Write Protect is off > | sd 0:0:0:0: rejecting I/O to offline device > | sda: asking for cache data failed > | sda: assuming drive cache: write through > | sd 0:0:0:0: Attached scsi disk sda > (...) > > mesh.c and mesh.h (in drivers/scsi/) are identical between the two versions, > so it seems that this is something at a different layer... > Maybe it's connected to http://marc.info/?l=linux-scsi&m=117596425706527&w=2 > but my test of 2.6.21-rc5 failed similarly to the test of 2.6.20. > > You can find kernel-config, full boot-time-output and build-logs at > http://www.geweb.net/tmp/linux-kernel/ > README contains the commands used (on a debian r3.1 sarge box) if you'd > like to check the builds (see linux-$VERSION for precise make-calls). > > I can test a version between the two mentioned above if you let me know which > one. There was a similar report for the imm driver, with a follow-up report that 2.6.21-rc5 works. Could you test 2.6.21-rc6? --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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
SCSI breakage on PowerMac 9500 (oldworld) between 2.6.19.7 and 2.6.20
Hi, it seems SCSI got broken somewhere on the way from 2.6.19.7 to 2.6.20 on oldworld Apple PowerMacs 9500 using the internal mesh-controller. The kernel fails to read the partition table from the drive(s) with the following messages: | mesh_host_reset | mesh: target 0 synchronous at 10.0 MB/s | sd 0:0:0:0: scsi: Device offlined - not ready after error recovery | sd 0:0:0:0: rejecting I/O to offline device | sd 0:0:0:0: rejecting I/O to offline device | sd 0:0:0:0: rejecting I/O to offline device | sd 0:0:0:0: rejecting I/O to offline device | sda : READ CAPACITY failed. | sda : status=0, message=00, host=1, driver=00 | sda : sense not available. | sd 0:0:0:0: rejecting I/O to offline device | sda: Write Protect is off | sd 0:0:0:0: rejecting I/O to offline device | sda: asking for cache data failed | sda: assuming drive cache: write through | sd 0:0:0:0: Attached scsi disk sda (...) mesh.c and mesh.h (in drivers/scsi/) are identical between the two versions, so it seems that this is something at a different layer... Maybe it's connected to http://marc.info/?l=linux-scsi&m=117596425706527&w=2 but my test of 2.6.21-rc5 failed similarly to the test of 2.6.20. You can find kernel-config, full boot-time-output and build-logs at http://www.geweb.net/tmp/linux-kernel/ README contains the commands used (on a debian r3.1 sarge box) if you'd like to check the builds (see linux-$VERSION for precise make-calls). I can test a version between the two mentioned above if you let me know which one. Martin -- /¯¯¯\ | PGP-Key 0x0F10B493 available via www.de.pgp.net, see header for fpr | \___/ - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.21-rc6-mm1 aacraid not finding device
On Sun, 2007-04-08 at 14:35 -0700, Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/ Since 2.6.21-rc5-mm1, one of the test.kernel.org machines (elm3b239) has not been able to boot because it cannot find the SCSI device. You can view http://test.kernel.org/abat/82623/debug/console.log for the latest boot log (rc6-mm1). I tracked this down to the git-scsi-misc patch in the -mm tree and then bisected the scsi-misc git tree until I reached the commit below from Mark Salyzyn: fe76df4235986cfacc2d3b71cef7c42bc1a6dd6c [SCSI] aacraid: Fix blocking issue with container probing function (cast update) This is a pretty big patch, so hopefully Mark can take a look at it. lspci shows 01:02.0 RAID bus controller: Adaptec AAC-RAID (rev 02) 0f:02.0 SCSI storage controller: Adaptec AIC-9410W SAS (Razor ASIC non-RAID) (rev 08) 1d:02.0 SCSI storage controller: Adaptec AIC-9410W SAS (Razor ASIC non-RAID) (rev 08) 2b:02.0 SCSI storage controller: Adaptec AIC-9410W SAS (Razor ASIC non-RAID) (rev 08) on 2.6.21-rc6. Let me know if I can provide more details. -- Steve Fox IBM Linux Technology Center - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 29/30] Use menuconfig objects - SCSI
Use menuconfigs instead of menus, so the whole menu can be disabled at once instead of going through all options. Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]> Index: linux-2.6.21-rc5/drivers/scsi/Kconfig === --- linux-2.6.21-rc5.orig/drivers/scsi/Kconfig +++ linux-2.6.21-rc5/drivers/scsi/Kconfig @@ -279,12 +279,16 @@ source "drivers/scsi/libsas/Kconfig" endmenu -menu "SCSI low-level drivers" +menuconfig SCSI_LOWLEVEL + bool "SCSI low-level drivers" depends on SCSI!=n + default y + +if SCSI_LOWLEVEL config ISCSI_TCP tristate "iSCSI Initiator over TCP/IP" - depends on SCSI && INET + depends on INET select CRYPTO select CRYPTO_MD5 select CRYPTO_CRC32C @@ -308,25 +312,25 @@ config ISCSI_TCP config SGIWD93_SCSI tristate "SGI WD93C93 SCSI Driver" - depends on SGI_IP22 && SCSI + depends on SGI_IP22 help If you have a Western Digital WD93 SCSI controller on an SGI MIPS system, say Y. Otherwise, say N. config SCSI_DECNCR tristate "DEC NCR53C94 Scsi Driver" - depends on MACH_DECSTATION && SCSI && TC + depends on MACH_DECSTATION && TC help Say Y here to support the NCR53C94 SCSI controller chips on IOASIC based TURBOchannel DECstations and TURBOchannel PMAZ-A cards. config SCSI_DECSII tristate "DEC SII Scsi Driver" - depends on MACH_DECSTATION && SCSI && 32BIT + depends on MACH_DECSTATION && 32BIT config BLK_DEV_3W__RAID tristate "3ware 5/6/7/8xxx ATA-RAID support" - depends on PCI && SCSI + depends on PCI help 3ware is the only hardware ATA-Raid product in Linux to date. This card is 2,4, or 8 channel master mode support only. @@ -339,7 +343,7 @@ config BLK_DEV_3W__RAID config SCSI_3W_9XXX tristate "3ware 9xxx SATA-RAID support" - depends on PCI && SCSI + depends on PCI help This driver supports the 9000 series 3ware SATA-RAID cards. @@ -350,7 +354,7 @@ config SCSI_3W_9XXX config SCSI_7000FASST tristate "7000FASST SCSI support" - depends on ISA && SCSI && ISA_DMA_API + depends on ISA && ISA_DMA_API help This driver supports the Western Digital 7000 SCSI host adapter family. Some information is in the source: @@ -361,7 +365,7 @@ config SCSI_7000FASST config SCSI_ACARD tristate "ACARD SCSI support" - depends on PCI && SCSI + depends on PCI help This driver supports the ACARD SCSI host adapter. Support Chip @@ -370,7 +374,7 @@ config SCSI_ACARD config SCSI_AHA152X tristate "Adaptec AHA152X/2825 support" - depends on ISA && SCSI && !64BIT + depends on ISA && !64BIT select SCSI_SPI_ATTRS ---help--- This is a driver for the AHA-1510, AHA-1520, AHA-1522, and AHA-2825 @@ -386,7 +390,7 @@ config SCSI_AHA152X config SCSI_AHA1542 tristate "Adaptec AHA1542 support" - depends on ISA && SCSI && ISA_DMA_API + depends on ISA && ISA_DMA_API ---help--- This is support for a SCSI host adapter. It is explained in section 3.4 of the SCSI-HOWTO, available from @@ -400,7 +404,7 @@ config SCSI_AHA1542 config SCSI_AHA1740 tristate "Adaptec AHA1740 support" - depends on EISA && SCSI + depends on EISA ---help--- This is support for a SCSI host adapter. It is explained in section 3.5 of the SCSI-HOWTO, available from @@ -413,7 +417,7 @@ config SCSI_AHA1740 config SCSI_AACRAID tristate "Adaptec AACRAID support" - depends on SCSI && PCI + depends on PCI help This driver supports a variety of Dell, HP, Adaptec, IBM and ICP storage products. For a list of supported products, refer @@ -427,7 +431,7 @@ source "drivers/scsi/aic7xxx/Kconfig.aic config SCSI_AIC7XXX_OLD tristate "Adaptec AIC7xxx support (old driver)" - depends on (ISA || EISA || PCI ) && SCSI + depends on ISA || EISA || PCI help WARNING This driver is an older aic7xxx driver and is no longer under active development. Adaptec, Inc. is writing a new driver to @@ -471,7 +475,7 @@ source "drivers/scsi/aic94xx/Kconfig" # All the I2O code and drivers do not seem to be 64bit safe. config SCSI_DPT_I2O tristate "Adaptec I2O RAID support " - depends on !64BIT && SCSI && PCI + depends on !64BIT && PCI help This driver supports all of Adaptec's I2O based RAID controllers as well as the DPT SmartRaid V cards. This is an Adaptec maintained @@ -482,7 +486,6 @@ config SCSI_DPT_I2O config SCSI_ADVANSYS tristate "AdvanSys SCSI support" - depends on SCSI depends on ISA || EISA || PCI depends on B
[PATCH 09/30] Use menuconfig objects - fusion
Use menuconfigs instead of menus, so the whole menu can be disabled at once instead of going through all options. Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]> Index: linux-2.6.21-rc5/drivers/message/fusion/Kconfig === --- linux-2.6.21-rc5.orig/drivers/message/fusion/Kconfig +++ linux-2.6.21-rc5/drivers/message/fusion/Kconfig @@ -1,14 +1,13 @@ -menu "Fusion MPT device support" +menuconfig FUSION + bool "Fusion MPT device support" + default y -config FUSION - bool - default n +if FUSION config FUSION_SPI tristate "Fusion MPT ScsiHost drivers for SPI" depends on PCI && SCSI - select FUSION select SCSI_SPI_ATTRS ---help--- SCSI HOST support for a parallel SCSI host adapters. @@ -23,7 +22,6 @@ config FUSION_SPI config FUSION_FC tristate "Fusion MPT ScsiHost drivers for FC" depends on PCI && SCSI - select FUSION select SCSI_FC_ATTRS ---help--- SCSI HOST support for a Fiber Channel host adapters. @@ -40,7 +38,6 @@ config FUSION_FC config FUSION_SAS tristate "Fusion MPT ScsiHost drivers for SAS" depends on PCI && SCSI - select FUSION select SCSI_SAS_ATTRS ---help--- SCSI HOST support for a SAS host adapters. @@ -54,7 +51,6 @@ config FUSION_SAS config FUSION_MAX_SGE int "Maximum number of scatter gather entries (16 - 128)" - depends on FUSION default "128" range 16 128 help @@ -100,4 +96,4 @@ config FUSION_LAN If unsure whether you really want or need this, say N. -endmenu +endif # FUSION # - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] cciss: set rq->errors more correctly in driver
PATCH 3/3
Set rq->errors more correctly in cciss driver. Previously
we had set it synonymously with the meaning of the last parameter
of end_that_last_request and complete_buffers (the "uptodate"
parameter) and had gotten away with it for all this time because
nobody ever looked at rq->errors. SCSI_IOCTL_SEND_COMMAND looks
at rq->errors, so now it matters that it be right.
Please consider this for inclusion.
Signed-off-by: Stephen M. Cameron <[EMAIL PROTECTED]>
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
---
linux-2.6.21-rc6/drivers/block/cciss.c | 43 -
1 files changed, 22 insertions(+), 21 deletions(-)
diff -puN linux-2.6.21-rc6/drivers/block/cciss.c~fix_cciss_rq_errors
linux-2.6.21-rc6/drivers/block/cciss.c
--- cciss_sg_io/linux-2.6.21-rc6/drivers/block/cciss.c~fix_cciss_rq_errors
2007-04-10 14:32:28.0 -0500
+++ cciss_sg_io-scameron/linux-2.6.21-rc6/drivers/block/cciss.c 2007-04-10
14:32:28.0 -0500
@@ -1261,7 +1261,7 @@ static void cciss_softirq_done(struct re
pci_unmap_page(h->pdev, temp64.val, cmd->SG[i].Len, ddir);
}
- complete_buffers(rq->bio, rq->errors);
+ complete_buffers(rq->bio, (rq->errors == 0));
if (blk_fs_request(rq)) {
const int rw = rq_data_dir(rq);
@@ -1275,7 +1275,7 @@ static void cciss_softirq_done(struct re
add_disk_randomness(rq->rq_disk);
spin_lock_irqsave(&h->lock, flags);
- end_that_request_last(rq, rq->errors);
+ end_that_request_last(rq, (rq->errors == 0));
cmd_free(h, cmd, 1);
cciss_check_queues(h);
spin_unlock_irqrestore(&h->lock, flags);
@@ -2366,27 +2366,27 @@ static inline void resend_cciss_cmd(ctlr
static inline int evaluate_target_status(CommandList_struct *cmd)
{
unsigned char sense_key;
- int status = 0; /* 0 means bad, 1 means good. */
+ int error_count = 1;
if (cmd->err_info->ScsiStatus != 0x02) { /* not check condition? */
if (!blk_pc_request(cmd->rq))
printk(KERN_WARNING "cciss: cmd %p "
"has SCSI Status 0x%x\n",
cmd, cmd->err_info->ScsiStatus);
- return status;
+ return error_count;
}
/* check the sense key */
sense_key = 0xf & cmd->err_info->SenseInfo[2];
/* no status or recovered error */
if ((sense_key == 0x0) || (sense_key == 0x1))
- status = 1;
+ error_count = 0;
if (!blk_pc_request(cmd->rq)) { /* Not SG_IO or similar? */
- if (status == 0)
+ if (error_count != 0)
printk(KERN_WARNING "cciss: cmd %p has CHECK CONDITION"
" sense key = 0x%x\n", cmd, sense_key);
- return status;
+ return error_count;
}
/* SG_IO or similar, copy sense data back */
@@ -2398,7 +2398,7 @@ static inline int evaluate_target_status
} else
cmd->rq->sense_len = 0;
- return status;
+ return error_count;
}
/* checks the status of the job and calls complete buffers to mark all
@@ -2408,18 +2408,20 @@ static inline int evaluate_target_status
static inline void complete_command(ctlr_info_t *h, CommandList_struct *cmd,
int timeout)
{
- int status = 1;
int retry_cmd = 0;
+ struct request *rq = cmd->rq;
+
+ rq->errors = 0;
if (timeout)
- status = 0;
+ rq->errors = 1;
if (cmd->err_info->CommandStatus == 0) /* no error has occurred */
goto after_error_processing;
switch (cmd->err_info->CommandStatus) {
case CMD_TARGET_STATUS:
- status = evaluate_target_status(cmd);
+ rq->errors = evaluate_target_status(cmd);
break;
case CMD_DATA_UNDERRUN:
if (blk_fs_request(cmd->rq)) {
@@ -2438,32 +2440,32 @@ static inline void complete_command(ctlr
case CMD_INVALID:
printk(KERN_WARNING "cciss: cmd %p is "
"reported invalid\n", cmd);
- status = 0;
+ rq->errors = 1;
break;
case CMD_PROTOCOL_ERR:
printk(KERN_WARNING "cciss: cmd %p has "
"protocol error \n", cmd);
- status = 0;
+ rq->errors = 1;
break;
case CMD_HARDWARE_ERR:
printk(KERN_WARNING "cciss: cmd %p had "
" hardware error\n", cmd);
- status = 0;
+ rq->errors = 1;
break;
case CMD_CONNECTION_LOST:
printk(KERN_WARNING "cciss: cmd %p had "
"connection lost\n", cmd);
- status = 0;
+ rq->errors = 1;
break;
[PATCH 2/3] cciss: add SG_IO ioctl to cciss
PATCH 2/3
For all of you that think cciss should be a scsi driver here is the patch that
you have been waiting for all these years. This patch actually adds the SG_IO
ioctl to cciss. The primary purpose is for clustering and high-availibilty.
But now anyone can exploit this ioctl in any manner they wish.
Note, SCSI_IOCTL_SEND_COMMAND doesn't work with this patch due to rq->errors
being set incorrectly. Subsequent patch fixes that.
Please consider this for inclusion.
Signed-off-by: Stephen M. Cameron <[EMAIL PROTECTED]>
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
---
linux-2.6.21-rc6/drivers/block/cciss.c | 164 ++---
1 files changed, 111 insertions(+), 53 deletions(-)
diff -puN linux-2.6.21-rc6/drivers/block/cciss.c~cciss_sg_io_ioctl
linux-2.6.21-rc6/drivers/block/cciss.c
--- cciss_sg_io/linux-2.6.21-rc6/drivers/block/cciss.c~cciss_sg_io_ioctl
2007-04-10 14:32:26.0 -0500
+++ cciss_sg_io-scameron/linux-2.6.21-rc6/drivers/block/cciss.c 2007-04-10
14:32:26.0 -0500
@@ -45,6 +45,9 @@
#include
#include
#include
+#include
+#include
+#include
#define CCISS_DRIVER_VERSION(maj,min,submin) ((maj<<16)|(min<<8)|(submin))
#define DRIVER_NAME "HP CISS Driver (v 3.6.14)"
@@ -1152,6 +1155,30 @@ static int cciss_ioctl(struct inode *ino
kfree(ioc);
return status;
}
+
+ /* scsi_cmd_ioctl handles these, below, though some are not */
+ /* very meaningful for cciss. SG_IO is the main one people want. */
+
+ case SG_GET_VERSION_NUM:
+ case SG_SET_TIMEOUT:
+ case SG_GET_TIMEOUT:
+ case SG_GET_RESERVED_SIZE:
+ case SG_SET_RESERVED_SIZE:
+ case SG_EMULATED_HOST:
+ case SG_IO:
+ case SCSI_IOCTL_SEND_COMMAND:
+ return scsi_cmd_ioctl(filep, disk, cmd, argp);
+
+ /* scsi_cmd_ioctl would normally handle these, below, but */
+ /* they aren't a good fit for cciss, as CD-ROMs are */
+ /* not supported, and we don't have any bus/target/lun */
+ /* which we present to the kernel. */
+
+ case CDROM_SEND_PACKET:
+ case CDROMCLOSETRAY:
+ case CDROMEJECT:
+ case SCSI_IOCTL_GET_IDLUN:
+ case SCSI_IOCTL_GET_BUS_NUMBER:
default:
return -ENOTTY;
}
@@ -2336,6 +2363,44 @@ static inline void resend_cciss_cmd(ctlr
start_io(h);
}
+static inline int evaluate_target_status(CommandList_struct *cmd)
+{
+ unsigned char sense_key;
+ int status = 0; /* 0 means bad, 1 means good. */
+
+ if (cmd->err_info->ScsiStatus != 0x02) { /* not check condition? */
+ if (!blk_pc_request(cmd->rq))
+ printk(KERN_WARNING "cciss: cmd %p "
+ "has SCSI Status 0x%x\n",
+ cmd, cmd->err_info->ScsiStatus);
+ return status;
+ }
+
+ /* check the sense key */
+ sense_key = 0xf & cmd->err_info->SenseInfo[2];
+ /* no status or recovered error */
+ if ((sense_key == 0x0) || (sense_key == 0x1))
+ status = 1;
+
+ if (!blk_pc_request(cmd->rq)) { /* Not SG_IO or similar? */
+ if (status == 0)
+ printk(KERN_WARNING "cciss: cmd %p has CHECK CONDITION"
+ " sense key = 0x%x\n", cmd, sense_key);
+ return status;
+ }
+
+ /* SG_IO or similar, copy sense data back */
+ if (cmd->rq->sense) {
+ if (cmd->rq->sense_len > cmd->err_info->SenseLen)
+ cmd->rq->sense_len = cmd->err_info->SenseLen;
+ memcpy(cmd->rq->sense, cmd->err_info->SenseInfo,
+ cmd->rq->sense_len);
+ } else
+ cmd->rq->sense_len = 0;
+
+ return status;
+}
+
/* checks the status of the job and calls complete buffers to mark all
* buffers for the completed job. Note that this function does not need
* to hold the hba/queue lock.
@@ -2353,37 +2418,22 @@ static inline void complete_command(ctlr
goto after_error_processing;
switch (cmd->err_info->CommandStatus) {
- unsigned char sense_key;
case CMD_TARGET_STATUS:
- status = 0;
-
- if (cmd->err_info->ScsiStatus == 0x02) {
- printk(KERN_WARNING "cciss: cmd %p "
- "has CHECK CONDITION "
- " byte 2 = 0x%x\n", cmd,
- cmd->err_info->SenseInfo[2]
- );
- /* check the sense key */
- sense_key = 0xf & cmd->err_info->SenseInfo[2];
- /* no status or recovered error */
- if ((sense_key == 0x0) || (sense_key == 0x1)) {
- status = 1;
- }
- } else {
-
[PATCH 1/3] cciss: reformat error handling
PATCH 1/3
This patch reformats some error handling code to reduce line lengths a bit. It
accompanies the SG_IO patch which is 2/3 of this set.
Please consider this for inclusion.
Signed-off-by: Stephen M. Cameron <[EMAIL PROTECTED]>
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
---
linux-2.6.21-rc6/drivers/block/cciss.c | 176 -
1 files changed, 90 insertions(+), 86 deletions(-)
diff -puN linux-2.6.21-rc6/drivers/block/cciss.c~reformat_error_handling
linux-2.6.21-rc6/drivers/block/cciss.c
--- cciss_sg_io/linux-2.6.21-rc6/drivers/block/cciss.c~reformat_error_handling
2007-04-10 14:22:46.0 -0500
+++ cciss_sg_io-scameron/linux-2.6.21-rc6/drivers/block/cciss.c 2007-04-10
14:31:58.0 -0500
@@ -2349,95 +2349,99 @@ static inline void complete_command(ctlr
if (timeout)
status = 0;
- if (cmd->err_info->CommandStatus != 0) {/* an error has
occurred */
- switch (cmd->err_info->CommandStatus) {
- unsigned char sense_key;
- case CMD_TARGET_STATUS:
- status = 0;
-
- if (cmd->err_info->ScsiStatus == 0x02) {
- printk(KERN_WARNING "cciss: cmd %p "
- "has CHECK CONDITION "
- " byte 2 = 0x%x\n", cmd,
- cmd->err_info->SenseInfo[2]
- );
- /* check the sense key */
- sense_key = 0xf & cmd->err_info->SenseInfo[2];
- /* no status or recovered error */
- if ((sense_key == 0x0) || (sense_key == 0x1)) {
- status = 1;
- }
- } else {
- printk(KERN_WARNING "cciss: cmd %p "
- "has SCSI Status 0x%x\n",
- cmd, cmd->err_info->ScsiStatus);
+ if (cmd->err_info->CommandStatus == 0) /* no error has occurred */
+ goto after_error_processing;
+
+ switch (cmd->err_info->CommandStatus) {
+ unsigned char sense_key;
+ case CMD_TARGET_STATUS:
+ status = 0;
+
+ if (cmd->err_info->ScsiStatus == 0x02) {
+ printk(KERN_WARNING "cciss: cmd %p "
+ "has CHECK CONDITION "
+ " byte 2 = 0x%x\n", cmd,
+ cmd->err_info->SenseInfo[2]
+ );
+ /* check the sense key */
+ sense_key = 0xf & cmd->err_info->SenseInfo[2];
+ /* no status or recovered error */
+ if ((sense_key == 0x0) || (sense_key == 0x1)) {
+ status = 1;
}
- break;
- case CMD_DATA_UNDERRUN:
- printk(KERN_WARNING "cciss: cmd %p has"
- " completed with data underrun "
- "reported\n", cmd);
- break;
- case CMD_DATA_OVERRUN:
- printk(KERN_WARNING "cciss: cmd %p has"
- " completed with data overrun "
- "reported\n", cmd);
- break;
- case CMD_INVALID:
- printk(KERN_WARNING "cciss: cmd %p is "
- "reported invalid\n", cmd);
- status = 0;
- break;
- case CMD_PROTOCOL_ERR:
- printk(KERN_WARNING "cciss: cmd %p has "
- "protocol error \n", cmd);
- status = 0;
- break;
- case CMD_HARDWARE_ERR:
- printk(KERN_WARNING "cciss: cmd %p had "
- " hardware error\n", cmd);
- status = 0;
- break;
- case CMD_CONNECTION_LOST:
- printk(KERN_WARNING "cciss: cmd %p had "
- "connection lost\n", cmd);
- status = 0;
- break;
- case CMD_ABORTED:
- printk(KERN_WARNING "cciss: cmd %p was "
- "aborted\n", cmd);
- status = 0;
- break;
- case CMD_ABORT_FAILED:
- printk(KERN_WARNING "cciss: cmd %p reports "
- "abort failed\n", cmd);
- status = 0;
- break;
- case CMD_UNSOLICITED_ABORT:
- printk(KERN_WARN
Disk spin up with esp on Sparc
Hi, I've noticed something strange as I've build and tested vanilla 2.6.20.3 for my Sparc Ultra-2: one of my hard disks wasn't spinning up. It was jumpered in a way where it would require a host command for spinning up. This ran OK with 2.6.14, which I had on that box before, though. [SMP kernel, 2 CPUs, 2 disks and one CD-ROM attached to the on-board esp SCSI, framebuffer and HME 4port ethernet SBUS card] I simply changed the jumpering and all was OK, disk spun up, filesystem got mounted, everything OK, but I wasn't really satisfied. I tried a very similar kernel config on my E250 (with make oldconfig), which I knew had some drives jumpered that way, too. Similar, because the E250 uses two SymbiosLogic 875 SCSI on-board hosts. The drives spun up without any problem. Now to the questions: does that mean that the low-level driver fires the motor start command? Or is that left to the generic sd driver and the esp driver simply fails to deliver the status of the drive to the upper layer or something like that? As the drives of the E250 spun up OK, I don't think that this is an intendend change of behaviour, but I really would like to debug this further. TIA for all hints and pointers, Uli -- Dipl. Inf. Ulrich Teichert|e-mail: [EMAIL PROTECTED] Stormweg 24 |listening to: Single (Hushpuppies), Pay The Cobra 24539 Neumuenster, Germany|(The Bellrays), Ne Me Touch Pas (Opération S) - 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
[Fwd: Fix BusLogic to stop using check_region]
Forwarded Message
Subject: Fix BusLogic to stop using check_region
From: Zachary Amsden <[EMAIL PROTECTED]>
I got so sick of seing the check_region warnings from BusLogic.c I actually
fixed it properly. Never use check region, reserve it before the probe
with request region instead and check the error result; free region if
setup fails. Should be functionally identical to the original except for
fixing the potential race.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
Cc: James Bottomley <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/scsi/BusLogic.c | 73 --
1 file changed, 48 insertions(+), 25 deletions(-)
diff -puN drivers/scsi/BusLogic.c~fix-buslogic-to-stop-using-check_region
drivers/scsi/BusLogic.c
--- a/drivers/scsi/BusLogic.c~fix-buslogic-to-stop-using-check_region
+++ a/drivers/scsi/BusLogic.c
@@ -579,17 +579,17 @@ static void __init BusLogic_InitializePr
/*
Append the list of standard BusLogic MultiMaster ISA I/O Addresses.
*/
- if (BusLogic_ProbeOptions.LimitedProbeISA ?
BusLogic_ProbeOptions.Probe330 : check_region(0x330,
BusLogic_MultiMasterAddressCount) == 0)
+ if (!BusLogic_ProbeOptions.LimitedProbeISA ||
BusLogic_ProbeOptions.Probe330)
BusLogic_AppendProbeAddressISA(0x330);
- if (BusLogic_ProbeOptions.LimitedProbeISA ?
BusLogic_ProbeOptions.Probe334 : check_region(0x334,
BusLogic_MultiMasterAddressCount) == 0)
+ if (!BusLogic_ProbeOptions.LimitedProbeISA ||
BusLogic_ProbeOptions.Probe334)
BusLogic_AppendProbeAddressISA(0x334);
- if (BusLogic_ProbeOptions.LimitedProbeISA ?
BusLogic_ProbeOptions.Probe230 : check_region(0x230,
BusLogic_MultiMasterAddressCount) == 0)
+ if (!BusLogic_ProbeOptions.LimitedProbeISA ||
BusLogic_ProbeOptions.Probe230)
BusLogic_AppendProbeAddressISA(0x230);
- if (BusLogic_ProbeOptions.LimitedProbeISA ?
BusLogic_ProbeOptions.Probe234 : check_region(0x234,
BusLogic_MultiMasterAddressCount) == 0)
+ if (!BusLogic_ProbeOptions.LimitedProbeISA ||
BusLogic_ProbeOptions.Probe234)
BusLogic_AppendProbeAddressISA(0x234);
- if (BusLogic_ProbeOptions.LimitedProbeISA ?
BusLogic_ProbeOptions.Probe130 : check_region(0x130,
BusLogic_MultiMasterAddressCount) == 0)
+ if (!BusLogic_ProbeOptions.LimitedProbeISA ||
BusLogic_ProbeOptions.Probe130)
BusLogic_AppendProbeAddressISA(0x130);
- if (BusLogic_ProbeOptions.LimitedProbeISA ?
BusLogic_ProbeOptions.Probe134 : check_region(0x134,
BusLogic_MultiMasterAddressCount) == 0)
+ if (!BusLogic_ProbeOptions.LimitedProbeISA ||
BusLogic_ProbeOptions.Probe134)
BusLogic_AppendProbeAddressISA(0x134);
}
@@ -795,7 +795,9 @@ static int __init BusLogic_InitializeMul
host adapters are probed.
*/
if (!BusLogic_ProbeOptions.NoProbeISA)
- if (PrimaryProbeInfo->IO_Address == 0 &&
(BusLogic_ProbeOptions.LimitedProbeISA ? BusLogic_ProbeOptions.Probe330 :
check_region(0x330, BusLogic_MultiMasterAddressCount) == 0)) {
+ if (PrimaryProbeInfo->IO_Address == 0 &&
+ (!BusLogic_ProbeOptions.LimitedProbeISA ||
+BusLogic_ProbeOptions.Probe330)) {
PrimaryProbeInfo->HostAdapterType =
BusLogic_MultiMaster;
PrimaryProbeInfo->HostAdapterBusType = BusLogic_ISA_Bus;
PrimaryProbeInfo->IO_Address = 0x330;
@@ -805,15 +807,25 @@ static int __init BusLogic_InitializeMul
omitting the Primary I/O Address which has already been handled.
*/
if (!BusLogic_ProbeOptions.NoProbeISA) {
- if (!StandardAddressSeen[1] &&
(BusLogic_ProbeOptions.LimitedProbeISA ? BusLogic_ProbeOptions.Probe334 :
check_region(0x334, BusLogic_MultiMasterAddressCount) == 0))
+ if (!StandardAddressSeen[1] &&
+ (!BusLogic_ProbeOptions.LimitedProbeISA ||
+BusLogic_ProbeOptions.Probe334))
BusLogic_AppendProbeAddressISA(0x334);
- if (!StandardAddressSeen[2] &&
(BusLogic_ProbeOptions.LimitedProbeISA ? BusLogic_ProbeOptions.Probe230 :
check_region(0x230, BusLogic_MultiMasterAddressCount) == 0))
+ if (!StandardAddressSeen[2] &&
+ (!BusLogic_ProbeOptions.LimitedProbeISA ||
+BusLogic_ProbeOptions.Probe230))
BusLogic_AppendProbeAddressISA(0x230);
- if (!StandardAddressSeen[3] &&
(BusLogic_ProbeOptions.LimitedProbeISA ? BusLogic_ProbeOptions.Probe234 :
check_region(0x234, BusLogic_MultiMasterAddressCount) == 0))
+ if (!StandardAddressSeen[3] &&
+ (!BusLogic_ProbeOptions.LimitedProbeISA ||
+
Linux 2007 File System & IO Workshop notes & talks
We have some of the material reviewed and posted now from the IO & FS workshop. USENIX has posted the talks at: http://www.usenix.org/events/lsf07/tech/tech.html A write up of the workshop went out at LWN and invoked a healthy discussion: http://lwn.net/Articles/226351/ At that LWN article, there is a link to the Linux FS wiki with good notes: http://linuxfs.pbwiki.com/LSF07-Workshop-Notes Another summary will go out in the next USENIX ;login edition. ric - 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
RAID1 can't be written after pulling out the secondary hard disk
Hi Eric,
We conducted the following test on a SUN Galaxy x64 server, then RAID1
can't be written anymore, fs become read-only. The steps of
reproducing the bug:
1. Create RAID1 with 2 disks (slot 0, 1) in LSI setup utility
2. Install RHEL5
3. Pull the disk(the secondary one) out from slot 1.
4. FS became read-only
5. dmesg shows a lot of errors
6 mount -oremount,rw /dev/sda2 can't recover fs to read-write state
We reproduced the bug with RHEL5(2.6.18-8.el5), kernel 2.6.18.8,
2.6.20.6 and 2.6.21-rc6.
But can't reproduce the bug with RHEL4-U4. It seems that the MPT
driver of version between 3.02 and 3.04 introduced this bug.
Let me know if you need other information.
Thanks,
Forrest
The log messages in dmesg:
--
mptbase: ioc0: RAID STATUS CHANGE for PhysDisk 0
mptbase: ioc0: PhysDisk is now missing
mptbase: ioc0: RAID STATUS CHANGE for PhysDisk 0
mptbase: ioc0: PhysDisk is now missing, out of sync
mptbase: ioc0: RAID STATUS CHANGE for VolumeID 0
mptbase: ioc0: volume is now degraded, enabled
mptbase: ioc0: LogInfo(0x3114): Originator={PL}, Code={IO
Executed}, SubCode(0x)
mptbase: ioc0: LogInfo(0x3114): Originator={PL}, Code={IO
Executed}, SubCode(0x)
mptsas: ioc0: removing ssp device, channel 0, id 1, phy 1
sd 0:1:0:0: SCSI error: return code = 0x0001
end_request: I/O error, dev sda, sector 266877
sd 0:1:0:0: SCSI error: return code = 0x0001
end_request: I/O error, dev sda, sector 9865
Buffer I/O error on device sda2, logical block 12304450
lost page write due to I/O error on sda2
mptscsih: ioc0: ERROR - Received a mf that was already freed
mptscsih: ioc0: ERROR - req_idx=1580 req_idx_MR=1580
mf=8803c9f42d80 mr= sc=880004821c00
Aborting journal on device sda2.
journal commit I/O error
ext3_abort called.
EXT3-fs error (device sda2): ext3_journal_start_sb: Detected aborted journal
Remounting filesystem read-only
mptscsih: ioc0: ERROR - Received a mf that was already freed
mptscsih: ioc0: ERROR - req_idx=2d80 req_idx_MR=2d80
mf=8803c9f52080 mr= sc=
--
The output of lspci:
--
00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev f3)
00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2)
00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev f2)
00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev f3)
00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev f3)
00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev f3)
00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:10.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8132 PCI-X Bridge (rev 12)
00:10.1 PIC: Advanced Micro Devices [AMD] AMD-8132 PCI-X IOAPIC (rev 12)
00:11.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8132 PCI-X Bridge (rev 12)
00:11.1 PIC: Advanced Micro Devices [AMD] AMD-8132 PCI-X IOAPIC (rev 12)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Miscellaneous Control
00:19.0 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] HyperTransport Technology Configuration
00:19.1 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Address Map
00:19.2 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] DRAM Controller
00:19.3 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Miscellaneous Control
00:1a.0 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] HyperTransport Technology Configuration
00:1a.1 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Address Map
00:1a.2 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] DRAM Controller
00:1a.3 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Miscellaneous Control
00:1b.0 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] HyperTransport Technology Configuration
00:1b.1 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Address Map
00:1b.2 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] DRAM Controller
00:1b.3 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Miscellaneous Control
01:06.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
06:01.0 Ethernet controller: Intel Corp
scsi_set_tag_type()
I don't believe this function behaves as some call sites intend. For example, if the driver implements the ->change_queue_type() method, and I say to use simple tags in sysfs, and sdev->ordered_tags is already set, I am not going to get simple tags since sdev->ordered_tags will stay set and scsi_get_tag_type() always returns MSG_ORDERED_TAG when sdev->ordered_tags is set. It's not "setting" the tag type, it's accumulating binary states until "0" is given which clears them all. Also, what is the thinking about what drivers should use as the default tag type via these interfaces? There appears to be a lot of inconsistency here. For example, unless overridden by the user, the aic7xxx driver uses orderred tags by default. On the other hand, libsas uses simple tags by default. Wouldn't we want to use simple tags by default to allow the target to reorder tagged requests as much as possible? Regardless of the thinking, I don't think this policy does not belong in the drivers at all. I'm trying to figure out what I should do in a driver I'm hacking on which is why I'm noticing all of this stuff :-) - 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
