Re: [PATCH] tmscsim: spin_unlock_irq in interrupt handler fix
Wow, been ages since the last patch to this driver has hit my mail:-) On Sat, 21 Jul 2012, Denis Efremov wrote: The replacement of spin_lock_irq/spin_unlock_irq pair in interrupt handler by spin_lock_irqsave/spin_lock_irqrestore pair. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Denis Efremov yefremov.de...@gmail.com Right, unconditionally enabling local IRQs in an ISR seems rude. BUT: unfortunately, it's not as easy as this. From DC390_Interrupt() dc390_DataOut_0() and dc390_DataIn_0() can be called, which also use spin_lock_irq() / spin_unlock_irq()... So, maybe adding a flags field to struct dc390_acb and using it on all 3 occasions would be the easiest and safest fix... Thanks Guennadi --- drivers/scsi/tmscsim.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/tmscsim.c b/drivers/scsi/tmscsim.c index a1baccc..0b9d68a 100644 --- a/drivers/scsi/tmscsim.c +++ b/drivers/scsi/tmscsim.c @@ -654,6 +654,7 @@ DC390_Interrupt(void *dev_id) u8 phase; void (*stateV)( struct dc390_acb*, struct dc390_srb*, u8 *); u8 istate, istatus; +unsigned long flags; sstatus = DC390_read8 (Scsi_Status); if( !(sstatus INTERRUPT) ) @@ -665,7 +666,7 @@ DC390_Interrupt(void *dev_id) //dstatus = DC390_read8 (DMA_Status); //DC390_write32 (DMA_ScsiBusCtrl, EN_INT_ON_PCI_ABORT); -spin_lock_irq(pACB-pScsiHost-host_lock); +spin_lock_irqsave(pACB-pScsiHost-host_lock, flags); istate = DC390_read8 (Intern_State); istatus = DC390_read8 (INT_Status); /* This clears Scsi_Status, Intern_State and INT_Status ! */ @@ -736,7 +737,7 @@ DC390_Interrupt(void *dev_id) } unlock: -spin_unlock_irq(pACB-pScsiHost-host_lock); +spin_unlock_irqrestore(pACB-pScsiHost-host_lock, flags); return IRQ_HANDLED; } -- 1.7.7 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/7] ZPODD patches
On Tue, 2012-07-31 at 10:40 +0800, Aaron Lu wrote: Hi James, Any chance of these patches get merged into 3.6? Not 3.6 given that the series was only finalised a week into the merge window. Generally because of the merge frenzy, linux-next doesn't work very well during this period so there's no way of getting any serious build test coverage. James -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] tmscsim: spin_unlock_irq in interrupt handler fix
The replacement of spin_lock_irq/spin_unlock_irq pairs which
can be called from interrupt handler by irqsave/irqrestore
versions.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Denis Efremov yefremov.de...@gmail.com
---
drivers/scsi/tmscsim.c | 12 ++--
drivers/scsi/tmscsim.h |1 +
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/tmscsim.c b/drivers/scsi/tmscsim.c
index a1baccc..e9b7148 100644
--- a/drivers/scsi/tmscsim.c
+++ b/drivers/scsi/tmscsim.c
@@ -665,7 +665,7 @@ DC390_Interrupt(void *dev_id)
//dstatus = DC390_read8 (DMA_Status);
//DC390_write32 (DMA_ScsiBusCtrl, EN_INT_ON_PCI_ABORT);
-spin_lock_irq(pACB-pScsiHost-host_lock);
+spin_lock_irqsave(pACB-pScsiHost-host_lock, pACB-hlock_flags);
istate = DC390_read8 (Intern_State);
istatus = DC390_read8 (INT_Status); /* This clears Scsi_Status,
Intern_State and INT_Status ! */
@@ -736,7 +736,7 @@ DC390_Interrupt(void *dev_id)
}
unlock:
-spin_unlock_irq(pACB-pScsiHost-host_lock);
+spin_unlock_irqrestore(pACB-pScsiHost-host_lock, pACB-hlock_flags);
return IRQ_HANDLED;
}
@@ -771,9 +771,9 @@ dc390_DataOut_0(struct dc390_acb* pACB, struct dc390_srb*
pSRB, u8 *psstatus)
/* Function called from the ISR with the host_lock held and
interrupts disabled */
if (pSRB-SGToBeXferLen)
while (time_before(jiffies, timeout) !((dstate = DC390_read8
(DMA_Status)) DMA_XFER_DONE)) {
- spin_unlock_irq(pACB-pScsiHost-host_lock);
+ spin_unlock_irqrestore(pACB-pScsiHost-host_lock,
pACB-hlock_flags);
udelay(50);
- spin_lock_irq(pACB-pScsiHost-host_lock);
+ spin_lock_irqsave(pACB-pScsiHost-host_lock,
pACB-hlock_flags);
}
if (!time_before(jiffies, timeout))
printk (KERN_CRIT DC390: Deadlock in DataOut_0: DMA aborted
unfinished: %06x bytes remain!!\n,
@@ -830,9 +830,9 @@ dc390_DataIn_0(struct dc390_acb* pACB, struct dc390_srb*
pSRB, u8 *psstatus)
/* Function called from the ISR with the host_lock held and
interrupts disabled */
if (pSRB-SGToBeXferLen)
while (time_before(jiffies, timeout) !((dstate = DC390_read8
(DMA_Status)) DMA_XFER_DONE)) {
- spin_unlock_irq(pACB-pScsiHost-host_lock);
+ spin_unlock_irqrestore(pACB-pScsiHost-host_lock,
pACB-hlock_flags);
udelay(50);
- spin_lock_irq(pACB-pScsiHost-host_lock);
+ spin_lock_irqsave(pACB-pScsiHost-host_lock,
pACB-hlock_flags);
}
if (!time_before(jiffies, timeout)) {
printk (KERN_CRIT DC390: Deadlock in DataIn_0: DMA aborted
unfinished: %06x bytes remain!!\n,
diff --git a/drivers/scsi/tmscsim.h b/drivers/scsi/tmscsim.h
index 77adc54..3f9ea2b 100644
--- a/drivers/scsi/tmscsim.h
+++ b/drivers/scsi/tmscsim.h
@@ -107,6 +107,7 @@ u8 SyncOffset; /*;for reg. and nego.(low
nibble) */
struct dc390_acb
{
struct Scsi_Host *pScsiHost;
+unsigned long hlock_flags;
u16IOPortBase;
u8 IRQLevel;
u8 status;
--
1.7.7
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scsi/ibmvscsi: add module alias for ibmvscsic
On 07/30/2012 10:08 PM, Benjamin Herrenschmidt wrote: On Mon, 2012-07-30 at 21:06 +0200, Olaf Hering wrote: So while this would work, I do wonder however whether we could instead fix it by simplifying the whole thing as follow since iSeries is now gone and so we don't need split backends anymore: scsi/ibmvscsi: Remove backend abstraction I cant that these things myself anymore. Brian, can somebody from your side own these ? I talked to Rob and he will be picking this up. Rob - can you submit a patch to the maintainers file, adding yourself as the ibmvscsi maintainer? Thanks, Brian -- Brian King Power Linux I/O IBM Linux Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scsi/ibmvscsi: add module alias for ibmvscsic
On Tue, Jul 31, 2012 at 11:20 AM, Brian King brk...@linux.vnet.ibm.com wrote: On 07/30/2012 10:08 PM, Benjamin Herrenschmidt wrote: On Mon, 2012-07-30 at 21:06 +0200, Olaf Hering wrote: So while this would work, I do wonder however whether we could instead fix it by simplifying the whole thing as follow since iSeries is now gone and so we don't need split backends anymore: scsi/ibmvscsi: Remove backend abstraction I cant that these things myself anymore. Brian, can somebody from your side own these ? I talked to Rob and he will be picking this up. Rob - can you submit a patch to the maintainers file, adding yourself as the ibmvscsi maintainer? I've submitted a patch for the MAINTAINERS file and I'll take a look at these patches to verify them as well. Thanks. --Rob Jennings -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ibmvscsi: Add maintainer for IBM virtual SCSI/FC drivers
Add a MAINTAINERS entry for the IBM Power Virtual SCSI and FC device drivers. Signed-off-by: Robert Jennings r...@linux.vnet.ibm.com --- MAINTAINERS |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index fb036a0..f441c46 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3425,6 +3425,13 @@ L: net...@vger.kernel.org S: Supported F: drivers/net/ethernet/ibm/ibmveth.* +IBM Power Virtual SCSI/FC Device Drivers +M: Robert Jennings r...@linux.vnet.ibm.com +L: linux-scsi@vger.kernel.org +S: Supported +F: drivers/scsi/ibmvscsi/ +X: drivers/scsi/ibmvscsi/ibmvstgt.c + IBM ServeRAID RAID DRIVER P: Jack Hammer M: Dave Jeffery ipsli...@adaptec.com -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
SCSI disk IO problem with JBOD
Hi Y'all, First let me apologize if this is the wrong venue to post this question. If it is not, please point me to the correct spot if possible! We have a Dell R610 server running CentOS 6.3 (kernel 2.6.32-279.2.1.el6.x86_64). We installed a LSI 9201-16e SAS HBA in it, upgraded to the latest firmware (9116 chipset). Then we attached a LSI DE2660 JBOD array to it, with 60 hard drives. At first boot, it got past grub to the initrd stage and crashed hard. A bunch of add_disk exceptions or something. If we unplugged the array, it boots fine. So then I had the idea to compile the RDAC driver and create a new initrd that preloads the RDAC driver: mkinitrd /boot/initrd-$(uname -r)-scsi_dh.img $(uname -r) --preload=scsi_dh_rdac Then I booted with that. It actually did not crash this time, but did spew a *ton* of SCSI errors on boot, like these (from dmesg): end_request: I/O error, dev sdbh, sector 0 end_request: I/O error, dev dm-57, sector 0 end_request: I/O error, dev dm-58, sector 0 mpt2sas0: log_info(0x3112043b): originator(PL), code(0x12), sub_code(0x043b) sd 0:0:10:0: [sdj] CDB: cdb[0]=0x7f, sa=0x9: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 end_request: I/O error, dev sdj, sector 0 end_request: I/O error, dev dm-59, sector 0 mpt2sas0: log_info(0x3112043b): originator(PL), code(0x12), sub_code(0x043b) sd 0:0:52:0: [sdaz] CDB: cdb[0]=0x7f, sa=0x9: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 end_request: I/O error, dev sdaz, sector 0 end_request: I/O error, dev dm-57, sector 0 mpt2sas0: log_info(0x3112043b): originator(PL), code(0x12), sub_code(0x043b) sd 0:0:60:0: [sdbh] CDB: cdb[0]=0x7f, sa=0x9: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 end_request: I/O error, dev sdbh, sector 0 end_request: I/O error, dev dm-58, sector 0 mpt2sas0: log_info(0x3112043b): originator(PL), code(0x12), sub_code(0x043b) sd 0:0:10:0: [sdj] CDB: cdb[0]=0x7f, sa=0x9: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 00 00 00 00 18 00 00 00 18 00 00 00 00 00 00 00 08 end_request: I/O error, dev sdj, sector 24 end_request: I/O error, dev dm-59, sector 24 mpt2sas0: log_info(0x3112043b): originator(PL), code(0x12), sub_code(0x043b) sd 0:0:43:0: [sdaq] CDB: cdb[0]=0x7f, sa=0x9: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 01 5d 50 a3 a8 5d 50 a3 a8 00 00 00 00 00 00 00 08 end_request: I/O error, dev sdaq, sector 5860533160 end_request: I/O error, dev dm-40, sector 5860533160 mpt2sas0: log_info(0x3112043b): originator(PL), code(0x12), sub_code(0x043b) mpt2sas0: log_info(0x3112043b): originator(PL), code(0x12), sub_code(0x043b) sd 0:0:60:0: [sdbh] CDB: cdb[0]=0x7f, sa=0x9: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 00 00 00 00 18 00 00 00 18 00 00 00 00 00 00 00 08 end_request: I/O error, dev sdbh, sector 24 sd 0:0:52:0: [sdaz] CDB: cdb[0]=0x7f, sa=0x9: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 00 00 00 00 18 00 00 00 18 00 00 00 00 00 00 00 08 end_request: I/O error, dev sdaz, sector 24 end_request: I/O error, dev dm-58, sector 24 end_request: I/O error, dev dm-57, sector 24 mpt2sas0: log_info(0x3112043b): originator(PL), code(0x12), sub_code(0x043b) mpt2sas0: log_info(0x3112043b): originator(PL), code(0x12), sub_code(0x043b) sd 0:0:53:0: [sdba] CDB: cdb[0]=0x7f, sa=0x9: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 01 5d 50 a3 a8 5d 50 a3 a8 00 00 00 00 00 00 00 08 end_request: I/O error, dev sdba, sector 5860533160 end_request: I/O error, dev dm-28, sector 5860533160 sd 0:0:43:0: [sdaq] CDB: cdb[0]=0x7f, sa=0x9: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 01 5d 50 a3 a8 5d 50 a3 a8 00 00 00 00 00 00 00 08 end_request: I/O error, dev sdaq, sector 5860533160 end_request: I/O error, dev dm-40, sector 5860533160 mpt2sas0: log_info(0x3112043b): originator(PL), code(0x12), sub_code(0x043b) sd 0:0:53:0: [sdba] CDB: cdb[0]=0x7f, sa=0x9: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 01 5d 50 a3 a8 5d 50 a3 a8 00 00 00 00 00 00 00 08 end_request: I/O error, dev sdba, sector 5860533160 end_request: I/O error, dev dm-28, sector 5860533160 mpt2sas0: log_info(0x3112043b): originator(PL), code(0x12), sub_code(0x043b) sd 0:0:53:0: [sdba] CDB: cdb[0]=0x7f, sa=0x9: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 end_request: I/O error, dev sdba, sector 0 end_request: I/O error, dev dm-28, sector 0 mpt2sas0: log_info(0x3112043b): originator(PL), code(0x12), sub_code(0x043b) sd 0:0:53:0: [sdba] CDB: cdb[0]=0x7f, sa=0x9: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 end_request: I/O error, dev sdba, sector 0 end_request: I/O error, dev dm-28, sector 0 mpt2sas0: log_info(0x3112043b): originator(PL), code(0x12), sub_code(0x043b) sd 0:0:53:0: [sdba] CDB: cdb[0]=0x7f, sa=0x9: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 00 00 00 00 18 00 00 00 18 00 00 00
Re: SCSI disk IO problem with JBOD
On 7/31/2012 11:00 PM, Erich Weiler wrote: Hi Y'all, First let me apologize if this is the wrong venue to post this question. If it is not, please point me to the correct spot if possible! We have a Dell R610 server running CentOS 6.3 (kernel 2.6.32-279.2.1.el6.x86_64). We installed a LSI 9201-16e SAS HBA in it, upgraded to the latest firmware (9116 chipset). Then we attached a LSI DE2660 JBOD array to it, with 60 hard drives. TTBOMK LSI never made a 60 drive JBOD chassis. Is this actually 3x 24 bay JBOD chassis daisy chained? Did you buy them on Ebay or are these simply being redeployed? All LSI drive chassis, both JBOD and SAN/DAS RAID, have been discontinued for quite a while. First remove and re-seat all SFF8088 cables. Then replace them one by one until the errors/problems are eliminated. If not test each chassis expander module individually with only one in the chassis. Test it in both module bays. Basic process of elimination stuff. Given you're receiving errors on multiple drives I'd say you have a bad: 1. Cable 2. Backplane 3. Expander module 4. PSU -- Stan -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SCSI disk IO problem with JBOD
Hi Stan, Thanks for replying! We have a Dell R610 server running CentOS 6.3 (kernel 2.6.32-279.2.1.el6.x86_64). We installed a LSI 9201-16e SAS HBA in it, upgraded to the latest firmware (9116 chipset). Then we attached a LSI DE2660 JBOD array to it, with 60 hard drives. TTBOMK LSI never made a 60 drive JBOD chassis. Is this actually 3x 24 bay JBOD chassis daisy chained? Did you buy them on Ebay or are these simply being redeployed? All LSI drive chassis, both JBOD and SAN/DAS RAID, have been discontinued for quite a while. Technically it is a E2660 Engenio expansion Array. These arrays are indeed 60 disks (in 4RU), they are front loading with 5 12-disk trays connected to a common backplane. NetApp recently acquired the LSI Engenio division, so I guess really it isn't LSI anymore, but now NetApp. It was purchased like 4 months ago right before NetApp took over the group. First remove and re-seat all SFF8088 cables. Then replace them one by one until the errors/problems are eliminated. If not test each chassis expander module individually with only one in the chassis. Test it in both module bays. Basic process of elimination stuff. I've not tried it with only one expander in the chassis, good idea. Given you're receiving errors on multiple drives I'd say you have a bad: 1. Cable 2. Backplane 3. Expander module 4. PSU Yeah something is weird, I seem to be receiving errors on every single drive. Either it's a driver issue or maybe even with the HBA, or something weird with the array/backplane. Thanks for the reply! cheers, erich -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
