RE: [2.6 patch] scsi/megaraid.c: __devexit annotation
Ack.
Regards,
Sumant
-Original Message-
From: Adrian Bunk [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 11, 2007 2:24 PM
To: DL-MegaRAID Linux; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org
Subject: [2.6 patch] scsi/megaraid.c: __devexit annotation
megaraid_remove_one() can become __devexit.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
b7d71f38d1c1aa66311e862b58f36aa34c888f98
diff --git a/drivers/scsi/megaraid.c b/drivers/scsi/megaraid.c index
66c6520..765c24d 100644
--- a/drivers/scsi/megaraid.c
+++ b/drivers/scsi/megaraid.c
@@ -4889,7 +4889,7 @@ __megaraid_shutdown(adapter_t *adapter)
mdelay(1000);
}
-static void
+static void __devexit
megaraid_remove_one(struct pci_dev *pdev) {
struct Scsi_Host *host = pci_get_drvdata(pdev);
--
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: [2.6 patch] scsi/megaraid.c: __devexit annotation
Ack.
Regards,
Sumant
-Original Message-
From: Adrian Bunk [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 11, 2007 2:24 PM
To: DL-MegaRAID Linux; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org
Subject: [2.6 patch] scsi/megaraid.c: __devexit annotation
megaraid_remove_one() can become __devexit.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
b7d71f38d1c1aa66311e862b58f36aa34c888f98
diff --git a/drivers/scsi/megaraid.c b/drivers/scsi/megaraid.c index
66c6520..765c24d 100644
--- a/drivers/scsi/megaraid.c
+++ b/drivers/scsi/megaraid.c
@@ -4889,7 +4889,7 @@ __megaraid_shutdown(adapter_t *adapter)
mdelay(1000);
}
-static void
+static void __devexit
megaraid_remove_one(struct pci_dev *pdev) {
struct Scsi_Host *host = pci_get_drvdata(pdev);
--
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: 2.6.23-rc9 boot failure (megaraid?)
> -Original Message-
> From: FUJITA Tomonori [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 02, 2007 5:01 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> linux-kernel@vger.kernel.org; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; Patro, Sumant; DL-MegaRAID
> Linux; [EMAIL PROTECTED]
> Subject: Re: 2.6.23-rc9 boot failure (megaraid?)
>
> On Tue, 02 Oct 2007 15:38:13 -0500
> James Bottomley <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 2007-10-02 at 20:15 +0200, Adrian Bunk wrote:
> > > Cc's added, the complete bug report is at
> > > http://lkml.org/lkml/2007/10/2/243
> > >
> > > On Tue, Oct 02, 2007 at 12:48:26PM -0400, Burton Windle wrote:
> > > > 2.6.23-rc9 fails to boot for me; 2.6.22.9 works fine.
> > > >
> > > > System is a Dell Poweredge with PERC 2/DC with RAID1 volume.
> > > >...
> > >
> > > Thanks for your report.
> > >
> > > Diff'ing the dmesg's shows:
> > >
> > > <-- snip -->
> > >
> > > scsi0: scanning scsi channel 4 [P0] for physical devices.
> > > scsi0: scanning scsi channel 5 [P1] for physical devices.
> > > st: Version 20070203, fixed bufsize 32768, s/g segs 256 -sd
> > > 0:0:0:0: [sda] 17547264 512-byte hardware sectors (8984 MB)
> > > +sd 0:0:0:0: [sda] Sector size 0 reported, assuming 512.
> > > +sd 0:0:0:0: [sda] 1 512-byte hardware sectors (0 MB)
> > > sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Asking
> > > for cache data failed sd 0:0:0:0: [sda] Assuming drive
> cache: write
> > > through -sd 0:0:0:0: [sda] 17547264 512-byte hardware
> sectors (8984
> > > MB)
> > > +sd 0:0:0:0: [sda] Sector size 0 reported, assuming 512.
> > > +sd 0:0:0:0: [sda] 1 512-byte hardware sectors (0 MB)
> > > sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Asking
> > > for cache data failed sd 0:0:0:0: [sda] Assuming drive
> cache: write
> > > through
> > > sda: sda1
> > > + sda: p1 exceeds device capacity
> > >
> > > <-- snip -->
> > >
> > > - case MEGA_BULK_DATA:
> > > - if (scb->cmd->use_sg == 0)
> > > - length = scb->cmd->request_bufflen;
> > > - else {
> > > - struct scatterlist *sgl =
> > > - (struct scatterlist
> *)scb->cmd->request_buffer;
> > > - length = sgl->length;
> > > - }
> > > - pci_unmap_page(adapter->dev, scb->dma_h_bulkdata,
> > > -length, scb->dma_direction);
> > > - break;
> > > -
> >
> > This is the problem piece I think. We've reintroduced a
> very old bug:
> >
> > commit 51c928c34fa7cff38df584ad01de988805877dba
> > Author: James Bottomley <[EMAIL PROTECTED]>
> > Date: Sat Oct 1 09:38:05 2005 -0500
> >
> > [SCSI] Legacy MegaRAID: Fix READ CAPACITY
> >
> > Some Legacy megaraid cards can't actually cope with the
> scatter/gather
> > version of the READ CAPACITY command (which is what we
> now send them
> > since altering all SCSI internal I/O to go via the
> block layer). Fix
> > this (and a few other broken megaraid driver
> assumptions) by sending
> > the non-sg version of the command if the sg list only
> has a single
> > element.
> >
> > Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
> >
> > So what we have to do is put back the check for use_sg == 1
> and send
> > that as a bulk transfer command.
>
> Sorry about this. Can this fix the problem?
>
> Thanks,
>
>
> diff --git a/drivers/scsi/megaraid.c
> b/drivers/scsi/megaraid.c index 3907f67..da56163 100644
> --- a/drivers/scsi/megaraid.c
> +++ b/drivers/scsi/megaraid.c
> @@ -1753,6 +1753,14 @@ mega_build_sglist(adapter_t *adapter,
> scb_t *scb, u32 *buf, u32 *len)
>
> *len = 0;
>
> + if (scsi_sg_count(cmd) == 1 && !adapter->has_64bit_addr) {
> + sg = scsi_sglist(cmd);
> + scb->dma_h_bulkdata = sg_dma_address(sg);
> + *buf = (u32)scb->dma_h_bulkdata;
> + *len = sg_dma_len(sg);
> + return 0;
> + }
> +
> scsi_for_each_sg(cmd, sg, sgcnt, idx) {
> if (adapter->has_64bit_addr) {
> scb->sgl64[idx].address = sg_dma_address(sg);
>
With this patch I see the correct logical disk size reported.
Thanks.
Sumant
-
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: 2.6.23-rc9 boot failure (megaraid?)
-Original Message-
From: FUJITA Tomonori [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 02, 2007 5:01 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
linux-kernel@vger.kernel.org; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Patro, Sumant; DL-MegaRAID
Linux; [EMAIL PROTECTED]
Subject: Re: 2.6.23-rc9 boot failure (megaraid?)
On Tue, 02 Oct 2007 15:38:13 -0500
James Bottomley [EMAIL PROTECTED] wrote:
On Tue, 2007-10-02 at 20:15 +0200, Adrian Bunk wrote:
Cc's added, the complete bug report is at
http://lkml.org/lkml/2007/10/2/243
On Tue, Oct 02, 2007 at 12:48:26PM -0400, Burton Windle wrote:
2.6.23-rc9 fails to boot for me; 2.6.22.9 works fine.
System is a Dell Poweredge with PERC 2/DC with RAID1 volume.
...
Thanks for your report.
Diff'ing the dmesg's shows:
-- snip --
scsi0: scanning scsi channel 4 [P0] for physical devices.
scsi0: scanning scsi channel 5 [P1] for physical devices.
st: Version 20070203, fixed bufsize 32768, s/g segs 256 -sd
0:0:0:0: [sda] 17547264 512-byte hardware sectors (8984 MB)
+sd 0:0:0:0: [sda] Sector size 0 reported, assuming 512.
+sd 0:0:0:0: [sda] 1 512-byte hardware sectors (0 MB)
sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Asking
for cache data failed sd 0:0:0:0: [sda] Assuming drive
cache: write
through -sd 0:0:0:0: [sda] 17547264 512-byte hardware
sectors (8984
MB)
+sd 0:0:0:0: [sda] Sector size 0 reported, assuming 512.
+sd 0:0:0:0: [sda] 1 512-byte hardware sectors (0 MB)
sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Asking
for cache data failed sd 0:0:0:0: [sda] Assuming drive
cache: write
through
sda: sda1
+ sda: p1 exceeds device capacity
-- snip --
- case MEGA_BULK_DATA:
- if (scb-cmd-use_sg == 0)
- length = scb-cmd-request_bufflen;
- else {
- struct scatterlist *sgl =
- (struct scatterlist
*)scb-cmd-request_buffer;
- length = sgl-length;
- }
- pci_unmap_page(adapter-dev, scb-dma_h_bulkdata,
-length, scb-dma_direction);
- break;
-
This is the problem piece I think. We've reintroduced a
very old bug:
commit 51c928c34fa7cff38df584ad01de988805877dba
Author: James Bottomley [EMAIL PROTECTED]
Date: Sat Oct 1 09:38:05 2005 -0500
[SCSI] Legacy MegaRAID: Fix READ CAPACITY
Some Legacy megaraid cards can't actually cope with the
scatter/gather
version of the READ CAPACITY command (which is what we
now send them
since altering all SCSI internal I/O to go via the
block layer). Fix
this (and a few other broken megaraid driver
assumptions) by sending
the non-sg version of the command if the sg list only
has a single
element.
Signed-off-by: James Bottomley [EMAIL PROTECTED]
So what we have to do is put back the check for use_sg == 1
and send
that as a bulk transfer command.
Sorry about this. Can this fix the problem?
Thanks,
diff --git a/drivers/scsi/megaraid.c
b/drivers/scsi/megaraid.c index 3907f67..da56163 100644
--- a/drivers/scsi/megaraid.c
+++ b/drivers/scsi/megaraid.c
@@ -1753,6 +1753,14 @@ mega_build_sglist(adapter_t *adapter,
scb_t *scb, u32 *buf, u32 *len)
*len = 0;
+ if (scsi_sg_count(cmd) == 1 !adapter-has_64bit_addr) {
+ sg = scsi_sglist(cmd);
+ scb-dma_h_bulkdata = sg_dma_address(sg);
+ *buf = (u32)scb-dma_h_bulkdata;
+ *len = sg_dma_len(sg);
+ return 0;
+ }
+
scsi_for_each_sg(cmd, sg, sgcnt, idx) {
if (adapter-has_64bit_addr) {
scb-sgl64[idx].address = sg_dma_address(sg);
With this patch I see the correct logical disk size reported.
Thanks.
Sumant
-
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: [PATCH 1/5] use mutex instead of semaphore in Megaraid Mailbox driver
Thank you Matthias for the patch.
Regards,
Sumant
-Original Message-
From: Matthias Kaehlcke [mailto:[EMAIL PROTECTED]
Sent: Sunday, July 01, 2007 9:29 AM
To: DL-MegaRAID Linux; [EMAIL PROTECTED]
Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED]
Subject: [PATCH 1/5] use mutex instead of semaphore in Megaraid Mailbox
driver
The Megaraid Mailbox driver uses a semaphore as mutex. Use the mutex API
instead of the (binary) semaphore.
Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>
--
diff --git a/drivers/scsi/megaraid/mega_common.h
b/drivers/scsi/megaraid/mega_common.h
index 26e1e6c..fef9ac9 100644
--- a/drivers/scsi/megaraid/mega_common.h
+++ b/drivers/scsi/megaraid/mega_common.h
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include
diff --git a/drivers/scsi/megaraid/megaraid_mbox.c
b/drivers/scsi/megaraid/megaraid_mbox.c
index 04d0b69..2cecc64 100644
--- a/drivers/scsi/megaraid/megaraid_mbox.c
+++ b/drivers/scsi/megaraid/megaraid_mbox.c
@@ -3957,7 +3957,7 @@ megaraid_sysfs_alloc_resources(adapter_t *adapter)
megaraid_sysfs_free_resources(adapter);
}
- sema_init(_dev->sysfs_sem, 1);
+ mutex_init(_dev->sysfs_mtx);
init_waitqueue_head(_dev->sysfs_wait_q);
@@ -4058,7 +4058,7 @@ megaraid_sysfs_get_ldmap(adapter_t *adapter)
/*
* Allow only one read at a time to go through the sysfs
attributes
*/
- down(_dev->sysfs_sem);
+ mutex_lock(_dev->sysfs_mtx);
uioc= raid_dev->sysfs_uioc;
mbox64 = raid_dev->sysfs_mbox64;
@@ -4134,7 +4134,7 @@ megaraid_sysfs_get_ldmap(adapter_t *adapter)
del_timer_sync(timerp);
- up(_dev->sysfs_sem);
+ mutex_unlock(_dev->sysfs_mtx);
return rval;
}
diff --git a/drivers/scsi/megaraid/megaraid_mbox.h
b/drivers/scsi/megaraid/megaraid_mbox.h
index 9de803c..626459d 100644
--- a/drivers/scsi/megaraid/megaraid_mbox.h
+++ b/drivers/scsi/megaraid/megaraid_mbox.h
@@ -168,7 +168,7 @@ typedef struct {
* @hw_error : set if FW not responding
* @fast_load : If set, skip physical device scanning
* @channel_class : channel class, RAID or SCSI
- * @sysfs_sem : semaphore to serialize access to sysfs
res.
+ * @sysfs_mtx : mutex to serialize access to sysfs
res.
* @sysfs_uioc : management packet to issue FW calls
from sysfs
* @sysfs_mbox64 : mailbox packet to issue FW calls from
sysfs
* @sysfs_buffer : data buffer for FW commands issued
from sysfs
@@ -208,7 +208,7 @@ typedef struct {
int hw_error;
int fast_load;
uint8_t channel_class;
- struct semaphoresysfs_sem;
+ struct mutexsysfs_mtx;
uioc_t *sysfs_uioc;
mbox64_t*sysfs_mbox64;
caddr_t sysfs_buffer;
--
Matthias Kaehlcke
Linux Application Developer
Barcelona
An ounce of practice is worth more than tons of preaching
(Mahatma Gandhi)
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
-
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: [PATCH 1/5] use mutex instead of semaphore in Megaraid Mailbox driver
Thank you Matthias for the patch.
Regards,
Sumant
-Original Message-
From: Matthias Kaehlcke [mailto:[EMAIL PROTECTED]
Sent: Sunday, July 01, 2007 9:29 AM
To: DL-MegaRAID Linux; [EMAIL PROTECTED]
Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED]
Subject: [PATCH 1/5] use mutex instead of semaphore in Megaraid Mailbox
driver
The Megaraid Mailbox driver uses a semaphore as mutex. Use the mutex API
instead of the (binary) semaphore.
Signed-off-by: Matthias Kaehlcke [EMAIL PROTECTED]
--
diff --git a/drivers/scsi/megaraid/mega_common.h
b/drivers/scsi/megaraid/mega_common.h
index 26e1e6c..fef9ac9 100644
--- a/drivers/scsi/megaraid/mega_common.h
+++ b/drivers/scsi/megaraid/mega_common.h
@@ -21,6 +21,7 @@
#include linux/types.h
#include linux/pci.h
#include linux/spinlock.h
+#include linux/mutex.h
#include linux/interrupt.h
#include linux/delay.h
#include linux/blkdev.h
diff --git a/drivers/scsi/megaraid/megaraid_mbox.c
b/drivers/scsi/megaraid/megaraid_mbox.c
index 04d0b69..2cecc64 100644
--- a/drivers/scsi/megaraid/megaraid_mbox.c
+++ b/drivers/scsi/megaraid/megaraid_mbox.c
@@ -3957,7 +3957,7 @@ megaraid_sysfs_alloc_resources(adapter_t *adapter)
megaraid_sysfs_free_resources(adapter);
}
- sema_init(raid_dev-sysfs_sem, 1);
+ mutex_init(raid_dev-sysfs_mtx);
init_waitqueue_head(raid_dev-sysfs_wait_q);
@@ -4058,7 +4058,7 @@ megaraid_sysfs_get_ldmap(adapter_t *adapter)
/*
* Allow only one read at a time to go through the sysfs
attributes
*/
- down(raid_dev-sysfs_sem);
+ mutex_lock(raid_dev-sysfs_mtx);
uioc= raid_dev-sysfs_uioc;
mbox64 = raid_dev-sysfs_mbox64;
@@ -4134,7 +4134,7 @@ megaraid_sysfs_get_ldmap(adapter_t *adapter)
del_timer_sync(timerp);
- up(raid_dev-sysfs_sem);
+ mutex_unlock(raid_dev-sysfs_mtx);
return rval;
}
diff --git a/drivers/scsi/megaraid/megaraid_mbox.h
b/drivers/scsi/megaraid/megaraid_mbox.h
index 9de803c..626459d 100644
--- a/drivers/scsi/megaraid/megaraid_mbox.h
+++ b/drivers/scsi/megaraid/megaraid_mbox.h
@@ -168,7 +168,7 @@ typedef struct {
* @hw_error : set if FW not responding
* @fast_load : If set, skip physical device scanning
* @channel_class : channel class, RAID or SCSI
- * @sysfs_sem : semaphore to serialize access to sysfs
res.
+ * @sysfs_mtx : mutex to serialize access to sysfs
res.
* @sysfs_uioc : management packet to issue FW calls
from sysfs
* @sysfs_mbox64 : mailbox packet to issue FW calls from
sysfs
* @sysfs_buffer : data buffer for FW commands issued
from sysfs
@@ -208,7 +208,7 @@ typedef struct {
int hw_error;
int fast_load;
uint8_t channel_class;
- struct semaphoresysfs_sem;
+ struct mutexsysfs_mtx;
uioc_t *sysfs_uioc;
mbox64_t*sysfs_mbox64;
caddr_t sysfs_buffer;
--
Matthias Kaehlcke
Linux Application Developer
Barcelona
An ounce of practice is worth more than tons of preaching
(Mahatma Gandhi)
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
-
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: megaraid.c, all kernel versions, problem with multi-luns
Please check with the server provider if multi-lun is supported with the adapter you are using. --Sumant -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Reinaldo Carvalho Sent: Wednesday, May 30, 2007 4:10 PM To: linux-kernel@vger.kernel.org Subject: megaraid.c, all kernel versions, problem with multi-luns Hi, I have a Dell PowerEdge Expandable RAID controller, with a hardware Raid-5 at Channel 01 running perfectly, and a nCipher Crypter at Channel 02. This controller doesn't correctly detect devices (e.g. nCipher Crypter) with multiples LUNs. Only one LUN is detected. At another controller (e.g. Adaptec 79xx) two LUNs were detect. I compiled 2.6.8, 2.6.18 and 2.6.21.3 to test megaraid driver and all failed detecting two LUNs. I think that this is a firmware problem, but i'd like have some opinions. I read some docs (http://www.suse.de/~garloff/linux/scsi-scan/scsi-scanning.html, http://www.ictp.trieste.it/~radionet/nuc1996/ref/howto-html/scsi-howto-2 .html) and this problem doesn't seem to be simple. Best regards, More information with Dell PowerEdge Expandable RAID controller (LSI Logic MegaRaid): Attached devices: Host: scsi0 Channel: 00 Id: 06 Lun: 00 Vendor: PE/PVModel: 1x5 SCSI BP Rev: 1.0 Type: ProcessorANSI SCSI revision: 02 Host: scsi0 Channel: 01 Id: 00 Lun: 00 Vendor: nCipher Model: Fastness Crypto Rev: 2*00 Type: ProcessorANSI SCSI revision: 02 Host: scsi0 Channel: 02 Id: 00 Lun: 00 Vendor: MegaRAID Model: LD 0 RAID5 279G Rev: 522A Type: Direct-AccessANSI SCSI revision: 02 14:0e.0 RAID bus controller: Dell PowerEdge Expandable RAID controller 4 (rev 06) Subsystem: Dell PowerEdge Expandable RAID Controller 4e/Di Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping+ SERR+ FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- 14:0e.0 0104: 1028:0013 (rev 06) Information with Adaptec 79xx or others SCSI controllers: Host: scsi0 Channel: 01 Id: 00 Lun: 00 Vendor: nCipher Model: Fastness Crypto Rev: 2*00 Type: ProcessorANSI SCSI revision: 02 Host: scsi0 Channel: 01 Id: 00 Lun: 01 Vendor: nCipher Model: Fastness Crypto Rev: 2*00 Type: ProcessorANSI SCSI revision: 02 -- Reinaldo Carvalho - 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/ - 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: LSI MegaRAID problems
I suspect the errors are coming because of bad disk(s).
Driver message indicates "reset" completed successfully.
--Sumant
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jules Colding
Sent: Wednesday, May 30, 2007 4:00 AM
To: linux-kernel
Subject: LSI MegaRAID problems
Hi,
I have a "LSI Logic MegaRAID SCSI 320-4x" adapter with an external raid5
array of 5 Seagate ST336754LW and XFS as fs on it. The device in
question is /dev/sdb and the box is a dual Opteron 252.
I've recently started to see this in the log almost whenever I touch the
filesystem:
May 30 12:22:56 omc-2 [ 1120.991356] megaraid: aborting-109150 cmd=28
May 30 12:22:56 omc-2 [ 1120.991366] megaraid abort:
109150:68[255:129], fw owner May 30 12:22:56 omc-2 [ 1120.991371]
megaraid: aborting-109151 cmd=28 May 30 12:22:56 omc-2 [
1120.991374] megaraid abort: 109151:64[255:129], fw owner May 30
12:22:56 omc-2 [ 1120.991379] megaraid: 2 outstanding commands. Max wait
300 sec May 30 12:22:56 omc-2 [ 1120.991382] megaraid mbox: Wait for 2
commands to complete:300 May 30 12:23:01 omc-2 [ 1126.006002] megaraid
mbox: Wait for 2 commands to complete:295 May 30 12:23:06 omc-2 [
1131.020774] megaraid mbox: Wait for 2 commands to complete:290 May 30
12:23:11 omc-2 [ 1136.035548] megaraid mbox: Wait for 2 commands to
complete:285 May 30 12:23:16 omc-2 [ 1141.050325] megaraid mbox: Wait
for 2 commands to complete:280 May 30 12:23:21 omc-2 [ 1146.065098]
megaraid mbox: Wait for 2 commands to complete:275 May 30 12:23:26 omc-2
[ 1151.083870] megaraid mbox: Wait for 0 commands to complete:270 May 30
12:23:26 omc-2 [ 1151.083874] megaraid mbox: reset sequence completed
sucessfully May 30 12:23:26 omc-2 [ 1151.083979] sd 0:4:1:0: SCSI error:
return code = 0x00040001 May 30 12:23:26 omc-2 [ 1151.083983]
end_request: I/O error, dev sdb, sector 95601663 May 30 12:23:26 omc-2 [
1151.084124] sd 0:4:1:0: SCSI error: return code = 0x00040001 May 30
12:23:26 omc-2 [ 1151.084128] end_request: I/O error, dev sdb, sector
95601535 May 30 12:23:26 omc-2 [ 1151.084332] sd 0:4:1:0: SCSI error:
return code = 0x00040001 May 30 12:23:26 omc-2 [ 1151.084334]
end_request: I/O error, dev sdb, sector 95601535 May 30 12:23:27 omc-2 [
1152.725763] sd 0:4:1:0: SCSI error: return code = 0x00040001 May 30
12:23:27 omc-2 [ 1152.725768] end_request: I/O error, dev sdb, sector
71411967 May 30 12:23:27 omc-2 [ 1152.725816] sd 0:4:1:0: SCSI error:
return code = 0x00040001 May 30 12:23:27 omc-2 [ 1152.725818]
end_request: I/O error, dev sdb, sector 71411967 May 30 12:23:31 omc-2 [
1156.578149] sd 0:4:1:0: SCSI error: return code = 0x00040001 May 30
12:23:31 omc-2 [ 1156.578156] end_request: I/O error, dev sdb, sector
143351464
May 30 12:23:31 omc-2 [ 1156.578173] I/O error in filesystem ("sdb1")
meta-data dev sdb1 block 0x88b5e69 ("xlog_iodone") error 5 buf
count 10752
May 30 12:23:31 omc-2 [ 1156.578178] xfs_force_shutdown(sdb1,0x2) called
from line 960 of file fs/xfs/xfs_log.c. Return address =
0x80398b56 May 30 12:23:31 omc-2 [ 1156.578204] Filesystem
"sdb1": Log I/O Error Detected. Shutting down filesystem: sdb1 May 30
12:23:31 omc-2 [ 1156.578207] Please umount the filesystem, and rectify
the problem(s) May 30 12:23:31 omc-2 [ 1156.578251] sd 0:4:1:0: SCSI
error: return code = 0x00040001 May 30 12:23:31 omc-2 [ 1156.578253]
end_request: I/O error, dev sdb, sector 63 May 30 12:24:13 omc-2 [
1198.747915] xfs_force_shutdown(sdb1,0x1) called from line 424 of file
fs/xfs/xfs_rw.c. Return address = 0x803afc2a
One of the drives in the array has been put offline after having seen
media errors. I'm waiting for a replacement but the recurring errors
worry me...
Any help/advises would be greatly appreciated.
Thanks a lot in advance,
jules
PS: I'm running a distribution kernel, but having seen zero responses on
the gentoo list I dared to write here. The kernel is gentoo-sources
2.6.20-r8.
-
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/
-
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: LSI MegaRAID problems
I suspect the errors are coming because of bad disk(s). Driver message indicates reset completed successfully. --Sumant -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jules Colding Sent: Wednesday, May 30, 2007 4:00 AM To: linux-kernel Subject: LSI MegaRAID problems Hi, I have a LSI Logic MegaRAID SCSI 320-4x adapter with an external raid5 array of 5 Seagate ST336754LW and XFS as fs on it. The device in question is /dev/sdb and the box is a dual Opteron 252. I've recently started to see this in the log almost whenever I touch the filesystem: May 30 12:22:56 omc-2 [ 1120.991356] megaraid: aborting-109150 cmd=28 c=4 t=1 l=0 May 30 12:22:56 omc-2 [ 1120.991366] megaraid abort: 109150:68[255:129], fw owner May 30 12:22:56 omc-2 [ 1120.991371] megaraid: aborting-109151 cmd=28 c=4 t=1 l=0 May 30 12:22:56 omc-2 [ 1120.991374] megaraid abort: 109151:64[255:129], fw owner May 30 12:22:56 omc-2 [ 1120.991379] megaraid: 2 outstanding commands. Max wait 300 sec May 30 12:22:56 omc-2 [ 1120.991382] megaraid mbox: Wait for 2 commands to complete:300 May 30 12:23:01 omc-2 [ 1126.006002] megaraid mbox: Wait for 2 commands to complete:295 May 30 12:23:06 omc-2 [ 1131.020774] megaraid mbox: Wait for 2 commands to complete:290 May 30 12:23:11 omc-2 [ 1136.035548] megaraid mbox: Wait for 2 commands to complete:285 May 30 12:23:16 omc-2 [ 1141.050325] megaraid mbox: Wait for 2 commands to complete:280 May 30 12:23:21 omc-2 [ 1146.065098] megaraid mbox: Wait for 2 commands to complete:275 May 30 12:23:26 omc-2 [ 1151.083870] megaraid mbox: Wait for 0 commands to complete:270 May 30 12:23:26 omc-2 [ 1151.083874] megaraid mbox: reset sequence completed sucessfully May 30 12:23:26 omc-2 [ 1151.083979] sd 0:4:1:0: SCSI error: return code = 0x00040001 May 30 12:23:26 omc-2 [ 1151.083983] end_request: I/O error, dev sdb, sector 95601663 May 30 12:23:26 omc-2 [ 1151.084124] sd 0:4:1:0: SCSI error: return code = 0x00040001 May 30 12:23:26 omc-2 [ 1151.084128] end_request: I/O error, dev sdb, sector 95601535 May 30 12:23:26 omc-2 [ 1151.084332] sd 0:4:1:0: SCSI error: return code = 0x00040001 May 30 12:23:26 omc-2 [ 1151.084334] end_request: I/O error, dev sdb, sector 95601535 May 30 12:23:27 omc-2 [ 1152.725763] sd 0:4:1:0: SCSI error: return code = 0x00040001 May 30 12:23:27 omc-2 [ 1152.725768] end_request: I/O error, dev sdb, sector 71411967 May 30 12:23:27 omc-2 [ 1152.725816] sd 0:4:1:0: SCSI error: return code = 0x00040001 May 30 12:23:27 omc-2 [ 1152.725818] end_request: I/O error, dev sdb, sector 71411967 May 30 12:23:31 omc-2 [ 1156.578149] sd 0:4:1:0: SCSI error: return code = 0x00040001 May 30 12:23:31 omc-2 [ 1156.578156] end_request: I/O error, dev sdb, sector 143351464 May 30 12:23:31 omc-2 [ 1156.578173] I/O error in filesystem (sdb1) meta-data dev sdb1 block 0x88b5e69 (xlog_iodone) error 5 buf count 10752 May 30 12:23:31 omc-2 [ 1156.578178] xfs_force_shutdown(sdb1,0x2) called from line 960 of file fs/xfs/xfs_log.c. Return address = 0x80398b56 May 30 12:23:31 omc-2 [ 1156.578204] Filesystem sdb1: Log I/O Error Detected. Shutting down filesystem: sdb1 May 30 12:23:31 omc-2 [ 1156.578207] Please umount the filesystem, and rectify the problem(s) May 30 12:23:31 omc-2 [ 1156.578251] sd 0:4:1:0: SCSI error: return code = 0x00040001 May 30 12:23:31 omc-2 [ 1156.578253] end_request: I/O error, dev sdb, sector 63 May 30 12:24:13 omc-2 [ 1198.747915] xfs_force_shutdown(sdb1,0x1) called from line 424 of file fs/xfs/xfs_rw.c. Return address = 0x803afc2a One of the drives in the array has been put offline after having seen media errors. I'm waiting for a replacement but the recurring errors worry me... Any help/advises would be greatly appreciated. Thanks a lot in advance, jules PS: I'm running a distribution kernel, but having seen zero responses on the gentoo list I dared to write here. The kernel is gentoo-sources 2.6.20-r8. - 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/ - 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: megaraid.c, all kernel versions, problem with multi-luns
Please check with the server provider if multi-lun is supported with the adapter you are using. --Sumant -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Reinaldo Carvalho Sent: Wednesday, May 30, 2007 4:10 PM To: linux-kernel@vger.kernel.org Subject: megaraid.c, all kernel versions, problem with multi-luns Hi, I have a Dell PowerEdge Expandable RAID controller, with a hardware Raid-5 at Channel 01 running perfectly, and a nCipher Crypter at Channel 02. This controller doesn't correctly detect devices (e.g. nCipher Crypter) with multiples LUNs. Only one LUN is detected. At another controller (e.g. Adaptec 79xx) two LUNs were detect. I compiled 2.6.8, 2.6.18 and 2.6.21.3 to test megaraid driver and all failed detecting two LUNs. I think that this is a firmware problem, but i'd like have some opinions. I read some docs (http://www.suse.de/~garloff/linux/scsi-scan/scsi-scanning.html, http://www.ictp.trieste.it/~radionet/nuc1996/ref/howto-html/scsi-howto-2 .html) and this problem doesn't seem to be simple. Best regards, More information with Dell PowerEdge Expandable RAID controller (LSI Logic MegaRaid): Attached devices: Host: scsi0 Channel: 00 Id: 06 Lun: 00 Vendor: PE/PVModel: 1x5 SCSI BP Rev: 1.0 Type: ProcessorANSI SCSI revision: 02 Host: scsi0 Channel: 01 Id: 00 Lun: 00 Vendor: nCipher Model: Fastness Crypto Rev: 2*00 Type: ProcessorANSI SCSI revision: 02 Host: scsi0 Channel: 02 Id: 00 Lun: 00 Vendor: MegaRAID Model: LD 0 RAID5 279G Rev: 522A Type: Direct-AccessANSI SCSI revision: 02 14:0e.0 RAID bus controller: Dell PowerEdge Expandable RAID controller 4 (rev 06) Subsystem: Dell PowerEdge Expandable RAID Controller 4e/Di Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping+ SERR+ FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 (32000ns min), Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 22 Region 0: Memory at d7ff (32-bit, prefetchable) [size=64K] Region 2: Memory at defc (32-bit, non-prefetchable) [size=256K] Expansion ROM at df00 [disabled] [size=128K] Capabilities: access denied 14:0e.0 0104: 1028:0013 (rev 06) Information with Adaptec 79xx or others SCSI controllers: Host: scsi0 Channel: 01 Id: 00 Lun: 00 Vendor: nCipher Model: Fastness Crypto Rev: 2*00 Type: ProcessorANSI SCSI revision: 02 Host: scsi0 Channel: 01 Id: 00 Lun: 01 Vendor: nCipher Model: Fastness Crypto Rev: 2*00 Type: ProcessorANSI SCSI revision: 02 -- Reinaldo Carvalho - 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/ - 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: [PATCH] scsi: megaraid_sas - intercepts cmd timeout andthrottle io
Hello James,
The rsvd[3] is reserved for future use. If you have objection to
the definition I will take it out in a future patch submission.
Regards,
Sumant
-Original Message-
From: James Bottomley [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 26, 2007 10:39 AM
To: Patro, Sumant
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
linux-kernel@vger.kernel.org; Kolli, Neela; Yang, Bo
Subject: Re: [PATCH] scsi: megaraid_sas - intercepts cmd timeout
andthrottle io
On Wed, 2007-03-28 at 10:43 -0700, Sumant Patro wrote:
> eh_timed_out call back (megasas_reset_timer) is used to throttle io to
> the adapter when it is called the first time for a scmd.
> The MEGASAS_FW_BUSY flag is set and can_queue reduced to 16. The
> can_queue is restored from completion routine in following two
> conditions : 5 seconds has elapsed and the # of outstanding cmds in FW
is < 17.
>
> Signed-off-by: Sumant Patro <[EMAIL PROTECTED]>
> ---
> drivers/scsi/megaraid/megaraid_sas.c | 65 +++--
> drivers/scsi/megaraid/megaraid_sas.h | 13 +++--
> 2 files changed, 70 insertions(+), 8 deletions(-)
>
> This patch requires the patch submitted by James with subject line :
>
> [PATCH] expose eh_timed_out to the host template
>
> diff -uprN linux-2.6.orig/drivers/scsi/megaraid/megaraid_sas.c
linux-2.6.new/drivers/scsi/megaraid/megaraid_sas.c
> --- linux-2.6.orig/drivers/scsi/megaraid/megaraid_sas.c
2007-03-28 08:41:49.0 -0700
> +++ linux-2.6.new/drivers/scsi/megaraid/megaraid_sas.c
2007-03-28 08:36:38.0 -0700
> @@ -10,7 +10,7 @@
> * 2 of the License, or (at your option) any later version.
> *
> * FILE : megaraid_sas.c
> - * Version : v00.00.03.10-rc1
> + * Version : v00.00.03.10-rc3
> *
> * Authors:
> * (email-id : [EMAIL PROTECTED])
> @@ -886,6 +886,7 @@ megasas_queue_command(struct scsi_cmnd *
> goto out_return_cmd;
>
> cmd->scmd = scmd;
> + scmd->SCp.ptr = (char *)cmd;
>
> /*
>* Issue the command to the FW
> @@ -981,8 +982,8 @@ static int megasas_generic_reset(struct
>
> instance = (struct megasas_instance
*)scmd->device->host->hostdata;
>
> - scmd_printk(KERN_NOTICE, scmd, "megasas: RESET -%ld cmd=%x\n",
> -scmd->serial_number, scmd->cmnd[0]);
> + scmd_printk(KERN_NOTICE, scmd, "megasas: RESET -%ld cmd=%x
retries=%x\n",
> + scmd->serial_number, scmd->cmnd[0], scmd->retries);
>
> if (instance->hw_crit_error) {
> printk(KERN_ERR "megasas: cannot recover from previous
reset "
> @@ -1000,6 +1001,40 @@ static int megasas_generic_reset(struct }
>
> /**
> + * megasas_reset_timer - quiesce the adapter if required
> + * @scmd:scsi cmnd
> + *
> + * Sets the FW busy flag and reduces the host->can_queue if the
> + * cmd has not been completed within the timeout period.
> + */
> +static enum
> +scsi_eh_timer_return megasas_reset_timer(struct scsi_cmnd *scmd) {
> + struct megasas_cmd *cmd = (struct megasas_cmd *)scmd->SCp.ptr;
> + struct megasas_instance *instance;
> + unsigned long flags;
> +
> + if (cmd) {
I don't believe we can ever get a command timeout with no command, can
we?
> + if (time_after(jiffies, scmd->jiffies_at_alloc + 170 *
HZ))
> + return EH_NOT_HANDLED;
This 170s is a bit arbitrary ... surely you want it to be related to a
multiple of scmd->timeout_per_command?
> + instance = cmd->instance;
> + if (!(instance->flag & MEGASAS_FW_BUSY)) {
> + /* FW is busy, throttle IO */
> + spin_lock_irqsave(>throttle_io_lock,
flags);
> +
> + instance->host->can_queue = 16;
can_queue is protected by the host lock ... I think you need to dump the
throttle_io_lock and simply use the host lock for all of this.
> + instance->last_time = jiffies;
> + instance->flag |= MEGASAS_FW_BUSY;
> +
> +
spin_unlock_irqrestore(>throttle_io_lock, flags);
> + }
> + return EH_RESET_TIMER;
> + }
> + return EH_HANDLED;
> +}
> +
> +/**
> * megasas_reset_device -Device reset handler entry point
> */
> static int megasas_reset_device(struct scsi_cmnd *scmd) @@ -1112,6
> +1147,7 @@ static struct scsi_host_template megasas
> .eh_device_reset_handler = megasas_reset_device,
> .eh_bus_reset_handler = megasas_reset_bus_host,
> .eh_host_reset_handler = megasas_reset_bus_host,
> + .eh_timed_out = megasas_reset_timer,
> .bios_par
RE: [PATCH] scsi: megaraid_sas - intercepts cmd timeout andthrottle io
Hello James,
The rsvd[3] is reserved for future use. If you have objection to
the definition I will take it out in a future patch submission.
Regards,
Sumant
-Original Message-
From: James Bottomley [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 26, 2007 10:39 AM
To: Patro, Sumant
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
linux-kernel@vger.kernel.org; Kolli, Neela; Yang, Bo
Subject: Re: [PATCH] scsi: megaraid_sas - intercepts cmd timeout
andthrottle io
On Wed, 2007-03-28 at 10:43 -0700, Sumant Patro wrote:
eh_timed_out call back (megasas_reset_timer) is used to throttle io to
the adapter when it is called the first time for a scmd.
The MEGASAS_FW_BUSY flag is set and can_queue reduced to 16. The
can_queue is restored from completion routine in following two
conditions : 5 seconds has elapsed and the # of outstanding cmds in FW
is 17.
Signed-off-by: Sumant Patro [EMAIL PROTECTED]
---
drivers/scsi/megaraid/megaraid_sas.c | 65 +++--
drivers/scsi/megaraid/megaraid_sas.h | 13 +++--
2 files changed, 70 insertions(+), 8 deletions(-)
This patch requires the patch submitted by James with subject line :
[PATCH] expose eh_timed_out to the host template
diff -uprN linux-2.6.orig/drivers/scsi/megaraid/megaraid_sas.c
linux-2.6.new/drivers/scsi/megaraid/megaraid_sas.c
--- linux-2.6.orig/drivers/scsi/megaraid/megaraid_sas.c
2007-03-28 08:41:49.0 -0700
+++ linux-2.6.new/drivers/scsi/megaraid/megaraid_sas.c
2007-03-28 08:36:38.0 -0700
@@ -10,7 +10,7 @@
* 2 of the License, or (at your option) any later version.
*
* FILE : megaraid_sas.c
- * Version : v00.00.03.10-rc1
+ * Version : v00.00.03.10-rc3
*
* Authors:
* (email-id : [EMAIL PROTECTED])
@@ -886,6 +886,7 @@ megasas_queue_command(struct scsi_cmnd *
goto out_return_cmd;
cmd-scmd = scmd;
+ scmd-SCp.ptr = (char *)cmd;
/*
* Issue the command to the FW
@@ -981,8 +982,8 @@ static int megasas_generic_reset(struct
instance = (struct megasas_instance
*)scmd-device-host-hostdata;
- scmd_printk(KERN_NOTICE, scmd, megasas: RESET -%ld cmd=%x\n,
-scmd-serial_number, scmd-cmnd[0]);
+ scmd_printk(KERN_NOTICE, scmd, megasas: RESET -%ld cmd=%x
retries=%x\n,
+ scmd-serial_number, scmd-cmnd[0], scmd-retries);
if (instance-hw_crit_error) {
printk(KERN_ERR megasas: cannot recover from previous
reset
@@ -1000,6 +1001,40 @@ static int megasas_generic_reset(struct }
/**
+ * megasas_reset_timer - quiesce the adapter if required
+ * @scmd:scsi cmnd
+ *
+ * Sets the FW busy flag and reduces the host-can_queue if the
+ * cmd has not been completed within the timeout period.
+ */
+static enum
+scsi_eh_timer_return megasas_reset_timer(struct scsi_cmnd *scmd) {
+ struct megasas_cmd *cmd = (struct megasas_cmd *)scmd-SCp.ptr;
+ struct megasas_instance *instance;
+ unsigned long flags;
+
+ if (cmd) {
I don't believe we can ever get a command timeout with no command, can
we?
+ if (time_after(jiffies, scmd-jiffies_at_alloc + 170 *
HZ))
+ return EH_NOT_HANDLED;
This 170s is a bit arbitrary ... surely you want it to be related to a
multiple of scmd-timeout_per_command?
+ instance = cmd-instance;
+ if (!(instance-flag MEGASAS_FW_BUSY)) {
+ /* FW is busy, throttle IO */
+ spin_lock_irqsave(instance-throttle_io_lock,
flags);
+
+ instance-host-can_queue = 16;
can_queue is protected by the host lock ... I think you need to dump the
throttle_io_lock and simply use the host lock for all of this.
+ instance-last_time = jiffies;
+ instance-flag |= MEGASAS_FW_BUSY;
+
+
spin_unlock_irqrestore(instance-throttle_io_lock, flags);
+ }
+ return EH_RESET_TIMER;
+ }
+ return EH_HANDLED;
+}
+
+/**
* megasas_reset_device -Device reset handler entry point
*/
static int megasas_reset_device(struct scsi_cmnd *scmd) @@ -1112,6
+1147,7 @@ static struct scsi_host_template megasas
.eh_device_reset_handler = megasas_reset_device,
.eh_bus_reset_handler = megasas_reset_bus_host,
.eh_host_reset_handler = megasas_reset_bus_host,
+ .eh_timed_out = megasas_reset_timer,
.bios_param = megasas_bios_param,
.use_clustering = ENABLE_CLUSTERING, }; @@ -1215,9 +1251,8 @@
megasas_complete_cmd(struct megasas_inst
int exception = 0;
struct megasas_header *hdr = cmd-frame-hdr;
- if (cmd-scmd) {
+ if (cmd-scmd)
cmd-scmd-SCp.ptr = (char *)0;
That's NULL, ordinarily ...
- }
switch (hdr-cmd) {
@@ -1806,6 +1841,7 @@ static void megasas_complete_cmd_dpc(uns
u32 context;
struct megasas_cmd *cmd;
struct
RE: [PATCH] scsi: megaraid_sas - throttle io if cmds are in riskof being timed-out
Thank you James. I will submit new patch that will throttle (if required) from eh_timed_out call back. Regards, Sumant -Original Message- From: James Bottomley [mailto:[EMAIL PROTECTED] Sent: Friday, March 16, 2007 3:23 PM To: Patro, Sumant Cc: [EMAIL PROTECTED]; linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org; Kolli, Neela; Yang, Bo Subject: Re: [PATCH] scsi: megaraid_sas - throttle io if cmds are in riskof being timed-out On Thu, 2007-03-01 at 13:29 -0800, Sumant Patro wrote: > Driver to throttle IO to reduce risk of OS timing out cmds. > > Implemented a circular queue to keep track of pending OS cmds in FW. > This queue is periodically (every 10 sec) checked by a timer routine. > If there is any cmd that is in risk of getting timed-out by the OS, > the host->can_queue is reduced to 16 and MEGASAS_FW_BUSY flag is set. > The host->can_queue will be restored to default value when the > following two conditions are met : 5 secs has elapsed and the # of > outstanding cmds in FW is less than 17. > Also increased the per cmd timeout to 120*HZ from 90*HZ. OK, this is still not nice. What you need to be doing is intercepting the timeout before it fires (and quiesces the machine). Currently the eh_timed_out() callback is only exposed to transport classes, I'll put it back into the host template and then you can use it. 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: [PATCH] scsi: megaraid_sas - throttle io if cmds are in riskof being timed-out
Thank you James. I will submit new patch that will throttle (if required) from eh_timed_out call back. Regards, Sumant -Original Message- From: James Bottomley [mailto:[EMAIL PROTECTED] Sent: Friday, March 16, 2007 3:23 PM To: Patro, Sumant Cc: [EMAIL PROTECTED]; linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org; Kolli, Neela; Yang, Bo Subject: Re: [PATCH] scsi: megaraid_sas - throttle io if cmds are in riskof being timed-out On Thu, 2007-03-01 at 13:29 -0800, Sumant Patro wrote: Driver to throttle IO to reduce risk of OS timing out cmds. Implemented a circular queue to keep track of pending OS cmds in FW. This queue is periodically (every 10 sec) checked by a timer routine. If there is any cmd that is in risk of getting timed-out by the OS, the host-can_queue is reduced to 16 and MEGASAS_FW_BUSY flag is set. The host-can_queue will be restored to default value when the following two conditions are met : 5 secs has elapsed and the # of outstanding cmds in FW is less than 17. Also increased the per cmd timeout to 120*HZ from 90*HZ. OK, this is still not nice. What you need to be doing is intercepting the timeout before it fires (and quiesces the machine). Currently the eh_timed_out() callback is only exposed to transport classes, I'll put it back into the host template and then you can use it. 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: [PATCH 3/5] scsi: megaraid_sas - throttle io if FW is busy
Hello James, It is difficult to know when the device will go into a state where it is not able to process cmds within timeout period consistently. Many factors may be contributing for the device to get into this state. Reducing can_queue may help but the difficult part is when does the can_queue value be restored to the original value. Because, the device may come back to normal functioning after some time. Also reducing it to a optimum value that will work for all possible cases is a challenge. In a typical setup the throttle io code may not get executed. It is required only when it has not been able to complete cmds more than 2 times within timeout period. Regards, Sumant -Original Message- From: James Bottomley [mailto:[EMAIL PROTECTED] Sent: Friday, February 16, 2007 9:51 AM To: Patro, Sumant Cc: [EMAIL PROTECTED]; linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org; Kolli, Neela; Yang, Bo Subject: RE: [PATCH 3/5] scsi: megaraid_sas - throttle io if FW is busy On Thu, 2007-02-15 at 19:53 -0700, Patro, Sumant wrote: > Hello James, > > I re-submitted the patch yesterday with the "space" issue fixed > (adhering to coding guideline). > > I will check for alternative to calculate the time driver have been > sending host busy to OS. Will check with time_before() as you have > suggested. > > Throttling from megasas_generic_reset() handler did not help. > megaraid does not have feature to abort cmds. So, in the generic reset > routine, the driver just waits for cmd completion by FW. These > timed-out cmds gets retried by mid-layer with "retries" incremented by 1. > Eventually we see retries equals max_allowed followed by SCSI error > with "DRIVER_TIMEOUT". That's rather what worries me. When the error handler activates (which it will on the first timeout), it waits for all commands to complete or time out before running. Your reset handler does nothing other than wait for the firmware to complete the commands (now uselessly), so we now wait for the entire firmware command queue to drain, then you tell the mid layer everything is OK, so it loads you up again with all the commands plus a few test unit readies for good measure, then you throttle. You really want to catch the device going into this condition and do something at that point ... prime candidate would be lowering the can_queue depth to get fewer commands transiting the firmware. 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: [PATCH 3/5] scsi: megaraid_sas - throttle io if FW is busy
Hello James, It is difficult to know when the device will go into a state where it is not able to process cmds within timeout period consistently. Many factors may be contributing for the device to get into this state. Reducing can_queue may help but the difficult part is when does the can_queue value be restored to the original value. Because, the device may come back to normal functioning after some time. Also reducing it to a optimum value that will work for all possible cases is a challenge. In a typical setup the throttle io code may not get executed. It is required only when it has not been able to complete cmds more than 2 times within timeout period. Regards, Sumant -Original Message- From: James Bottomley [mailto:[EMAIL PROTECTED] Sent: Friday, February 16, 2007 9:51 AM To: Patro, Sumant Cc: [EMAIL PROTECTED]; linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org; Kolli, Neela; Yang, Bo Subject: RE: [PATCH 3/5] scsi: megaraid_sas - throttle io if FW is busy On Thu, 2007-02-15 at 19:53 -0700, Patro, Sumant wrote: Hello James, I re-submitted the patch yesterday with the space issue fixed (adhering to coding guideline). I will check for alternative to calculate the time driver have been sending host busy to OS. Will check with time_before() as you have suggested. Throttling from megasas_generic_reset() handler did not help. megaraid does not have feature to abort cmds. So, in the generic reset routine, the driver just waits for cmd completion by FW. These timed-out cmds gets retried by mid-layer with retries incremented by 1. Eventually we see retries equals max_allowed followed by SCSI error with DRIVER_TIMEOUT. That's rather what worries me. When the error handler activates (which it will on the first timeout), it waits for all commands to complete or time out before running. Your reset handler does nothing other than wait for the firmware to complete the commands (now uselessly), so we now wait for the entire firmware command queue to drain, then you tell the mid layer everything is OK, so it loads you up again with all the commands plus a few test unit readies for good measure, then you throttle. You really want to catch the device going into this condition and do something at that point ... prime candidate would be lowering the can_queue depth to get fewer commands transiting the firmware. 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: [PATCH 3/5] scsi: megaraid_sas - throttle io if FW is busy
Hello James,
I re-submitted the patch yesterday with the "space" issue fixed
(adhering to coding guideline).
I will check for alternative to calculate the time driver have
been sending host busy to OS. Will check with time_before() as you have
suggested.
Throttling from megasas_generic_reset() handler did not help.
megaraid does not have feature to abort cmds. So, in the generic reset
routine, the driver just waits for cmd completion by FW. These timed-out
cmds gets retried by mid-layer with "retries" incremented by 1.
Eventually we see retries equals max_allowed followed by SCSI error with
"DRIVER_TIMEOUT".
By throttling from the megasas_queue_command we do not hit the
issue. In our test with this code, retries did not exceed 2.
Regards,
Sumant
-Original Message-
From: James Bottomley [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 15, 2007 4:11 PM
To: Patro, Sumant
Cc: [EMAIL PROTECTED]; linux-scsi@vger.kernel.org;
linux-kernel@vger.kernel.org; Kolli, Neela; Yang, Bo; Patro, Sumant
Subject: Re: [PATCH 3/5] scsi: megaraid_sas - throttle io if FW is busy
On Tue, 2007-02-06 at 14:11 -0800, Sumant Patro wrote:
> Checks added in megasas_queue_command to know if FW is able to process
> commands within timeout period. If number of retries is 2 or greater,
> the driver stops sending cmd to FW. IO is resumed if pending cmd count
> reduces to 16 or 5 seconds has elapsed from the time cmds were last
> sent to FW.
>
> Signed-off-by: Sumant Patro <[EMAIL PROTECTED]>
> ---
>
> drivers/scsi/megaraid/megaraid_sas.c | 27 +
> drivers/scsi/megaraid/megaraid_sas.h |3 ++
> 2 files changed, 30 insertions(+)
>
> diff -uprN 2.6.new-p2/drivers/scsi/megaraid/megaraid_sas.c
2.6.new-p3/drivers/scsi/megaraid/megaraid_sas.c
> --- 2.6.new-p2/drivers/scsi/megaraid/megaraid_sas.c 2007-02-06
08:43:40.0 -0800
> +++ 2.6.new-p3/drivers/scsi/megaraid/megaraid_sas.c 2007-02-06
08:50:40.0 -0800
> @@ -839,6 +839,7 @@ megasas_queue_command(struct scsi_cmnd *
> u32 frame_count;
> struct megasas_cmd *cmd;
> struct megasas_instance *instance;
> + unsigned long sec;
>
> instance = (struct megasas_instance *)
> scmd->device->host->hostdata;
> @@ -856,6 +857,23 @@ megasas_queue_command(struct scsi_cmnd *
> goto out_done;
> }
>
> + /* Check if we can process cmds */
> + if(instance->is_busy){
^ ^
space needed per linux coding style (and the rest of the file
> + sec = (jiffies - instance->last_time) / HZ;
please don't do this. You want to be using time_before() and
jiffies_to_msecs(). The space problems apply to the rest of the code
> + if(sec<5)
> + return SCSI_MLQUEUE_HOST_BUSY;
> + else{
> + instance->is_busy=0;
> + instance->last_time=0;
> + }
> + }
> +
> + if(scmd->retries>1){
I really don't think this is a good indicator of your firmware
necessarily having problems; I really think you might want to look at
other indicators ... jiffies_at_alloc might be better, or even
throttling from the abort handler, which must have been called before
you get to here if the command is actually timing out.
Timeout and abort has it's own throttle anyway, since we quiesce the
host before beginning error recovery ... are you sure this scheme
actually solves anything for your device?
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: [PATCH 3/6] scsi: megaraid_sas - throttle io if FW is busy
Yes I can make it boolean.
Will change it in a future patch submission.
Thanks,
Sumant
-Original Message-
From: Richard Knutsson [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 15, 2007 12:10 AM
To: Patro, Sumant
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org; Kolli, Neela;
Yang, Bo; Patro, Sumant
Subject: Re: [PATCH 3/6] scsi: megaraid_sas - throttle io if FW is busy
Sumant Patro wrote:
> Checks added in megasas_queue_command to know if FW is able to process
> commands within the timeout period. If number of retries is 2 or more,
> the driver stops sending cmd to FW. IO is resumed when pending cmd
> count reduces to 16 or 10 seconds has elapsed from the time cmds were
> last sent to FW.
>
> Signed-off-by: Sumant Patro <[EMAIL PROTECTED]>
> ---
>
> drivers/scsi/megaraid/megaraid_sas.c | 27 +
> drivers/scsi/megaraid/megaraid_sas.h |3 ++
> 2 files changed, 30 insertions(+)
>
>
[snip]
> diff -uprN linux-feb13-new-p2/drivers/scsi/megaraid/megaraid_sas.h
linux-feb13-new-p3/drivers/scsi/megaraid/megaraid_sas.h
> --- linux-feb13-new-p2/drivers/scsi/megaraid/megaraid_sas.h
2007-02-13 07:22:40.0 -0800
> +++ linux-feb13-new-p3/drivers/scsi/megaraid/megaraid_sas.h
2007-02-13 11:37:09.0 -0800
> @@ -1102,6 +1102,9 @@ struct megasas_instance {
> atomic_t fw_outstanding;
> u32 hw_crit_error;
>
> + u8 is_busy;
>
Why not "bool is_busy:8;"? It obviously is a boolean. I would also think
false/true would be more descriptive then 0/1.
Richard Knutsson
-
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: [PATCH 3/6] scsi: megaraid_sas - throttle io if FW is busy
Yes I can make it boolean.
Will change it in a future patch submission.
Thanks,
Sumant
-Original Message-
From: Richard Knutsson [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 15, 2007 12:10 AM
To: Patro, Sumant
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org; Kolli, Neela;
Yang, Bo; Patro, Sumant
Subject: Re: [PATCH 3/6] scsi: megaraid_sas - throttle io if FW is busy
Sumant Patro wrote:
Checks added in megasas_queue_command to know if FW is able to process
commands within the timeout period. If number of retries is 2 or more,
the driver stops sending cmd to FW. IO is resumed when pending cmd
count reduces to 16 or 10 seconds has elapsed from the time cmds were
last sent to FW.
Signed-off-by: Sumant Patro [EMAIL PROTECTED]
---
drivers/scsi/megaraid/megaraid_sas.c | 27 +
drivers/scsi/megaraid/megaraid_sas.h |3 ++
2 files changed, 30 insertions(+)
[snip]
diff -uprN linux-feb13-new-p2/drivers/scsi/megaraid/megaraid_sas.h
linux-feb13-new-p3/drivers/scsi/megaraid/megaraid_sas.h
--- linux-feb13-new-p2/drivers/scsi/megaraid/megaraid_sas.h
2007-02-13 07:22:40.0 -0800
+++ linux-feb13-new-p3/drivers/scsi/megaraid/megaraid_sas.h
2007-02-13 11:37:09.0 -0800
@@ -1102,6 +1102,9 @@ struct megasas_instance {
atomic_t fw_outstanding;
u32 hw_crit_error;
+ u8 is_busy;
Why not bool is_busy:8;? It obviously is a boolean. I would also think
false/true would be more descriptive then 0/1.
Richard Knutsson
-
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: [PATCH 3/5] scsi: megaraid_sas - throttle io if FW is busy
Hello James,
I re-submitted the patch yesterday with the space issue fixed
(adhering to coding guideline).
I will check for alternative to calculate the time driver have
been sending host busy to OS. Will check with time_before() as you have
suggested.
Throttling from megasas_generic_reset() handler did not help.
megaraid does not have feature to abort cmds. So, in the generic reset
routine, the driver just waits for cmd completion by FW. These timed-out
cmds gets retried by mid-layer with retries incremented by 1.
Eventually we see retries equals max_allowed followed by SCSI error with
DRIVER_TIMEOUT.
By throttling from the megasas_queue_command we do not hit the
issue. In our test with this code, retries did not exceed 2.
Regards,
Sumant
-Original Message-
From: James Bottomley [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 15, 2007 4:11 PM
To: Patro, Sumant
Cc: [EMAIL PROTECTED]; linux-scsi@vger.kernel.org;
linux-kernel@vger.kernel.org; Kolli, Neela; Yang, Bo; Patro, Sumant
Subject: Re: [PATCH 3/5] scsi: megaraid_sas - throttle io if FW is busy
On Tue, 2007-02-06 at 14:11 -0800, Sumant Patro wrote:
Checks added in megasas_queue_command to know if FW is able to process
commands within timeout period. If number of retries is 2 or greater,
the driver stops sending cmd to FW. IO is resumed if pending cmd count
reduces to 16 or 5 seconds has elapsed from the time cmds were last
sent to FW.
Signed-off-by: Sumant Patro [EMAIL PROTECTED]
---
drivers/scsi/megaraid/megaraid_sas.c | 27 +
drivers/scsi/megaraid/megaraid_sas.h |3 ++
2 files changed, 30 insertions(+)
diff -uprN 2.6.new-p2/drivers/scsi/megaraid/megaraid_sas.c
2.6.new-p3/drivers/scsi/megaraid/megaraid_sas.c
--- 2.6.new-p2/drivers/scsi/megaraid/megaraid_sas.c 2007-02-06
08:43:40.0 -0800
+++ 2.6.new-p3/drivers/scsi/megaraid/megaraid_sas.c 2007-02-06
08:50:40.0 -0800
@@ -839,6 +839,7 @@ megasas_queue_command(struct scsi_cmnd *
u32 frame_count;
struct megasas_cmd *cmd;
struct megasas_instance *instance;
+ unsigned long sec;
instance = (struct megasas_instance *)
scmd-device-host-hostdata;
@@ -856,6 +857,23 @@ megasas_queue_command(struct scsi_cmnd *
goto out_done;
}
+ /* Check if we can process cmds */
+ if(instance-is_busy){
^ ^
space needed per linux coding style (and the rest of the file
+ sec = (jiffies - instance-last_time) / HZ;
please don't do this. You want to be using time_before() and
jiffies_to_msecs(). The space problems apply to the rest of the code
+ if(sec5)
+ return SCSI_MLQUEUE_HOST_BUSY;
+ else{
+ instance-is_busy=0;
+ instance-last_time=0;
+ }
+ }
+
+ if(scmd-retries1){
I really don't think this is a good indicator of your firmware
necessarily having problems; I really think you might want to look at
other indicators ... jiffies_at_alloc might be better, or even
throttling from the abort handler, which must have been called before
you get to here if the command is actually timing out.
Timeout and abort has it's own throttle anyway, since we quiesce the
host before beginning error recovery ... are you sure this scheme
actually solves anything for your device?
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: [PATCH] scsi/megaraid.c: pci_module_init to pci_register_driver
ACK.
--Sumant
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Richard Knutsson
Sent: Tuesday, February 13, 2007 4:41 PM
To: Kolli, Neela
Cc: linux-kernel@vger.kernel.org; linux-scsi@vger.kernel.org; Richard
Knutsson
Subject: [PATCH] scsi/megaraid.c: pci_module_init to pci_register_driver
Convert pci_module_init() to pci_register_driver().
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested with "allyes", "allmod" & "allno" on i386
diff --git a/drivers/scsi/megaraid.c b/drivers/scsi/megaraid.c index
808a1b8..0aa3304 100644
--- a/drivers/scsi/megaraid.c
+++ b/drivers/scsi/megaraid.c
@@ -5072,7 +5072,7 @@ static int __init megaraid_init(void)
"megaraid: failed to create megaraid
root\n");
}
#endif
- error = pci_module_init(_pci_driver);
+ error = pci_register_driver(_pci_driver);
if (error) {
#ifdef CONFIG_PROC_FS
remove_proc_entry("megaraid", _root);
-
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
-
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: [PATCH] scsi/megaraid.c: pci_module_init to pci_register_driver
ACK.
--Sumant
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Richard Knutsson
Sent: Tuesday, February 13, 2007 4:41 PM
To: Kolli, Neela
Cc: linux-kernel@vger.kernel.org; linux-scsi@vger.kernel.org; Richard
Knutsson
Subject: [PATCH] scsi/megaraid.c: pci_module_init to pci_register_driver
Convert pci_module_init() to pci_register_driver().
Signed-off-by: Richard Knutsson [EMAIL PROTECTED]
---
Compile-tested with allyes, allmod allno on i386
diff --git a/drivers/scsi/megaraid.c b/drivers/scsi/megaraid.c index
808a1b8..0aa3304 100644
--- a/drivers/scsi/megaraid.c
+++ b/drivers/scsi/megaraid.c
@@ -5072,7 +5072,7 @@ static int __init megaraid_init(void)
megaraid: failed to create megaraid
root\n);
}
#endif
- error = pci_module_init(megaraid_pci_driver);
+ error = pci_register_driver(megaraid_pci_driver);
if (error) {
#ifdef CONFIG_PROC_FS
remove_proc_entry(megaraid, proc_root);
-
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
-
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: [PATCH 1/5] scsi: megaraid_sas - stop cmd processing if hw_crit_error is set
I will correct the formatting and will resubmit.
Regards,
Sumant
-Original Message-
From: Andrew Morton [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 07, 2007 1:18 PM
To: Patro, Sumant
Cc: [EMAIL PROTECTED]; linux-scsi@vger.kernel.org;
linux-kernel@vger.kernel.org; Kolli, Neela; Yang, Bo; Patro, Sumant
Subject: Re: [PATCH 1/5] scsi: megaraid_sas - stop cmd processing if
hw_crit_error is set
On Tue, 06 Feb 2007 13:49:24 -0800
Sumant Patro <[EMAIL PROTECTED]> wrote:
> + /* Don't process if we have already declared adapter dead */
> + if(instance->hw_crit_error)
Preferred kernel coding style is "if (".
> [p1-crit_err.patch text/x-patch (1.3KB)]
argh. Please don't send two copies of the patch in the email. Because
the result applies happily with `patch --dry-run' and then creates a
great mess when you try to apply the patch for real.
-
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: [PATCH 4/5] scsi: megaraid_sas - preallocate memory for ioctlprocessing
Thanks. I will resubmit the patch. Regards, Sumant -Original Message- From: James Bottomley [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 07, 2007 2:02 PM To: Andrew Morton Cc: Patro, Sumant; linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org; Kolli, Neela; Yang, Bo; Patro, Sumant Subject: Re: [PATCH 4/5] scsi: megaraid_sas - preallocate memory for ioctlprocessing On Wed, 2007-02-07 at 13:30 -0800, Andrew Morton wrote: > I suspect all this horror is due to stupidity in the DMA API. > > pci_alloc_consistent() just goes and assumes GFP_ATOMIC, whereas the > caller (megasas_mgmt_fw_ioctl) would have been perfectly happy to use > GFP_KERNEL. > > I bet this fixes it It does, but the DMA API was expanded to cope with this exact case, so use dma_alloc_coherent() directly in the megaraid code instead. The dev is just _dev->dev. 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: [PATCH 4/5] scsi: megaraid_sas - preallocate memory for ioctlprocessing
Thanks. I will resubmit the patch. Regards, Sumant -Original Message- From: James Bottomley [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 07, 2007 2:02 PM To: Andrew Morton Cc: Patro, Sumant; linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org; Kolli, Neela; Yang, Bo; Patro, Sumant Subject: Re: [PATCH 4/5] scsi: megaraid_sas - preallocate memory for ioctlprocessing On Wed, 2007-02-07 at 13:30 -0800, Andrew Morton wrote: I suspect all this horror is due to stupidity in the DMA API. pci_alloc_consistent() just goes and assumes GFP_ATOMIC, whereas the caller (megasas_mgmt_fw_ioctl) would have been perfectly happy to use GFP_KERNEL. I bet this fixes it It does, but the DMA API was expanded to cope with this exact case, so use dma_alloc_coherent() directly in the megaraid code instead. The dev is just pci_dev-dev. 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: [PATCH 1/5] scsi: megaraid_sas - stop cmd processing if hw_crit_error is set
I will correct the formatting and will resubmit. Regards, Sumant -Original Message- From: Andrew Morton [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 07, 2007 1:18 PM To: Patro, Sumant Cc: [EMAIL PROTECTED]; linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org; Kolli, Neela; Yang, Bo; Patro, Sumant Subject: Re: [PATCH 1/5] scsi: megaraid_sas - stop cmd processing if hw_crit_error is set On Tue, 06 Feb 2007 13:49:24 -0800 Sumant Patro [EMAIL PROTECTED] wrote: + /* Don't process if we have already declared adapter dead */ + if(instance-hw_crit_error) Preferred kernel coding style is if (. [p1-crit_err.patch text/x-patch (1.3KB)] argh. Please don't send two copies of the patch in the email. Because the result applies happily with `patch --dry-run' and then creates a great mess when you try to apply the patch for real. - 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: Re: [PATCH] scsi: megaraid_{mm,mbox} init fix for kdump
The patch is specific to kdump scenario.
What I see in the log is cmd timeout(s) and is not related to the patch.
--Sumant
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matthias Urlichs
Sent: Wednesday, January 31, 2007 9:50 AM
To: linux-scsi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] scsi: megaraid_{mm,mbox} init fix for kdump
On Fri, 05 Jan 2007 07:10:09 -0800, Sumant Patro wrote:
> This command clears the pending commands in the adapter
> and re-initialize its internal RAID structure.
> Without this change, megaraid driver either panics or fails to
> initialize the adapter during kdump's second kernel boot
> if there are pending commands or interrupts from other devices
> sharing the same IRQ.
Nice. Is there a chance that this patch will also fix the regression
I've noticed (today, unfortunately) on (at least one) Dell server?
FWIW, here's the relevant LSPCI output and kernel logs:
0d:0e.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID (rev 07)
Subsystem: Dell Unknown device 0002
Flags: bus master, stepping, 66MHz, medium devsel, latency 64,
IRQ 18
Memory at d80f (32-bit, prefetchable) [size=64K]
Memory at fc4c (32-bit, non-prefetchable) [size=256K]
Expansion ROM at fc50 [disabled] [size=128K]
Capabilities: [c0] Power Management version 2
Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+
Queue=0/1 Enable-
Capabilities: [e0] PCI-X non-bridge device
Jan 31 14:41:34 kernel: [ 232.873327] megaraid cmm: 2.20.2.7 (Release
Date: Sun Jul 16 00:01:03 EST 2006) Jan 31 14:41:34 kernel: [
232.877616] SCSI subsystem initialized Jan 31 14:41:34 kernel: [
232.888779] megaraid: 2.20.4.9 (Release Date: Sun Jul 16 12:27:22 EST
2006) Jan 31 14:41:34 kernel: [ 232.889835] megasas: 00.00.03.05 Mon Oct
02 11:21:32 PDT 2006 Jan 31 14:41:34 kernel: [ 233.513659] megasas:
0x1028:0x0015:0x1028:0x1f03: <6>megaraid: probe new device
0x1000:0x0408:0x1028:0x0002: bus 13:slot 14:func 0 Jan 31 14:41:34
kernel: [ 233.514770] megasas: FW now in Ready state Jan 31 14:41:34
kernel: [ 233.528893] megaraid: fw version:[522A] bios version:[H430]
Jan 31 14:41:34 kernel: [ 233.554778] scsi2 : LSI Logic SAS based
MegaRAID driver Jan 31 14:41:34 kernel: [ 233.36] scsi 2:0:0:0:
Direct-Access MAXTOR ATLAS10K5_073SAS BP00 PQ: 0 ANSI: 5 Jan 31 14:41:34
kernel: [ 233.556173] scsi 2:0:1:0: Direct-Access MAXTOR
ATLAS10K5_073SAS BP00 PQ: 0 ANSI: 5 Jan 31 14:41:34 kernel: [
233.569337] scsi3 : LSI Logic MegaRAID driver Jan 31 14:41:34 kernel: [
233.569550] scsi[3]: scanning scsi channel 0 [Phy 0] for non-raid
devices Jan 31 14:41:34 kernel: [ 233.604522] scsi 2:0:8:0: Enclosure DP
BACKPLANE 1.00 PQ: 0 ANSI: 5 Jan 31 14:41:41 kernel: [ 243.115199]
megaraid: aborting-16 cmd=12 Jan 31 14:41:41 kernel: [
243.115206] megaraid abort: 16:0[0:12], fw owner Jan 31 14:41:41 kernel:
[ 243.115217] megaraid: 1 outstanding commands. Max wait 300 sec Jan 31
14:41:41 kernel: [ 243.115221] megaraid mbox: Wait for 1 commands to
complete:300 Jan 31 14:41:46 kernel: [ 248.125812] megaraid mbox: Wait
for 1 commands to complete:295 Jan 31 14:41:48 kernel: [ 250.134075]
megaraid mbox: reset sequence completed sucessfully Jan 31 14:41:58
kernel: [ 260.117201] megaraid: aborting-16 cmd=0 Jan 31
14:41:58 kernel: [ 260.117207] megaraid abort: 16:0[0:12], fw owner Jan
31 14:41:58 kernel: [ 260.117217] megaraid: 1 outstanding commands. Max
wait 300 sec Jan 31 14:41:58 kernel: [ 260.117223] megaraid mbox: Wait
for 1 commands to complete:300 Jan 31 14:42:03 kernel: [ 265.127417]
megaraid mbox: Wait for 1 commands to complete:295 Jan 31 14:42:08
kernel: [ 270.140211] megaraid mbox: Wait for 1 commands to complete:290
Jan 31 14:42:12 kernel: [ 274.146803] megaraid mbox: reset sequence
completed sucessfully [ nothing else that appears relevant ]
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de |
[EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. |
http://smurf.noris.de
- -
Those who welcome death have only tried it from the ears up.
-- Wilson Mizner
-
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
-
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: Re: [PATCH] scsi: megaraid_{mm,mbox} init fix for kdump
The patch is specific to kdump scenario.
What I see in the log is cmd timeout(s) and is not related to the patch.
--Sumant
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matthias Urlichs
Sent: Wednesday, January 31, 2007 9:50 AM
To: linux-scsi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] scsi: megaraid_{mm,mbox} init fix for kdump
On Fri, 05 Jan 2007 07:10:09 -0800, Sumant Patro wrote:
This command clears the pending commands in the adapter
and re-initialize its internal RAID structure.
Without this change, megaraid driver either panics or fails to
initialize the adapter during kdump's second kernel boot
if there are pending commands or interrupts from other devices
sharing the same IRQ.
Nice. Is there a chance that this patch will also fix the regression
I've noticed (today, unfortunately) on (at least one) Dell server?
FWIW, here's the relevant LSPCI output and kernel logs:
0d:0e.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID (rev 07)
Subsystem: Dell Unknown device 0002
Flags: bus master, stepping, 66MHz, medium devsel, latency 64,
IRQ 18
Memory at d80f (32-bit, prefetchable) [size=64K]
Memory at fc4c (32-bit, non-prefetchable) [size=256K]
Expansion ROM at fc50 [disabled] [size=128K]
Capabilities: [c0] Power Management version 2
Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+
Queue=0/1 Enable-
Capabilities: [e0] PCI-X non-bridge device
Jan 31 14:41:34 kernel: [ 232.873327] megaraid cmm: 2.20.2.7 (Release
Date: Sun Jul 16 00:01:03 EST 2006) Jan 31 14:41:34 kernel: [
232.877616] SCSI subsystem initialized Jan 31 14:41:34 kernel: [
232.888779] megaraid: 2.20.4.9 (Release Date: Sun Jul 16 12:27:22 EST
2006) Jan 31 14:41:34 kernel: [ 232.889835] megasas: 00.00.03.05 Mon Oct
02 11:21:32 PDT 2006 Jan 31 14:41:34 kernel: [ 233.513659] megasas:
0x1028:0x0015:0x1028:0x1f03: 6megaraid: probe new device
0x1000:0x0408:0x1028:0x0002: bus 13:slot 14:func 0 Jan 31 14:41:34
kernel: [ 233.514770] megasas: FW now in Ready state Jan 31 14:41:34
kernel: [ 233.528893] megaraid: fw version:[522A] bios version:[H430]
Jan 31 14:41:34 kernel: [ 233.554778] scsi2 : LSI Logic SAS based
MegaRAID driver Jan 31 14:41:34 kernel: [ 233.36] scsi 2:0:0:0:
Direct-Access MAXTOR ATLAS10K5_073SAS BP00 PQ: 0 ANSI: 5 Jan 31 14:41:34
kernel: [ 233.556173] scsi 2:0:1:0: Direct-Access MAXTOR
ATLAS10K5_073SAS BP00 PQ: 0 ANSI: 5 Jan 31 14:41:34 kernel: [
233.569337] scsi3 : LSI Logic MegaRAID driver Jan 31 14:41:34 kernel: [
233.569550] scsi[3]: scanning scsi channel 0 [Phy 0] for non-raid
devices Jan 31 14:41:34 kernel: [ 233.604522] scsi 2:0:8:0: Enclosure DP
BACKPLANE 1.00 PQ: 0 ANSI: 5 Jan 31 14:41:41 kernel: [ 243.115199]
megaraid: aborting-16 cmd=12 c=0 t=12 l=0 Jan 31 14:41:41 kernel: [
243.115206] megaraid abort: 16:0[0:12], fw owner Jan 31 14:41:41 kernel:
[ 243.115217] megaraid: 1 outstanding commands. Max wait 300 sec Jan 31
14:41:41 kernel: [ 243.115221] megaraid mbox: Wait for 1 commands to
complete:300 Jan 31 14:41:46 kernel: [ 248.125812] megaraid mbox: Wait
for 1 commands to complete:295 Jan 31 14:41:48 kernel: [ 250.134075]
megaraid mbox: reset sequence completed sucessfully Jan 31 14:41:58
kernel: [ 260.117201] megaraid: aborting-16 cmd=0 c=0 t=12 l=0Jan 31
14:41:58 kernel: [ 260.117207] megaraid abort: 16:0[0:12], fw owner Jan
31 14:41:58 kernel: [ 260.117217] megaraid: 1 outstanding commands. Max
wait 300 sec Jan 31 14:41:58 kernel: [ 260.117223] megaraid mbox: Wait
for 1 commands to complete:300 Jan 31 14:42:03 kernel: [ 265.127417]
megaraid mbox: Wait for 1 commands to complete:295 Jan 31 14:42:08
kernel: [ 270.140211] megaraid mbox: Wait for 1 commands to complete:290
Jan 31 14:42:12 kernel: [ 274.146803] megaraid mbox: reset sequence
completed sucessfully [ nothing else that appears relevant ]
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de |
[EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. |
http://smurf.noris.de
- -
Those who welcome death have only tried it from the ears up.
-- Wilson Mizner
-
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
-
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: [PATCH] scsi: megaraid_{mm,mbox} init fix for kdump
Hello Randy,
At this time I am not trying to modify the function comment
style of existing megaraid_mbox code. For the new function the
description style is in sync with the preexisting code.
So, I request for the patch to be accepted in its current
submitted form.
Regards,
Sumant
-Original Message-
From: Randy Dunlap [mailto:[EMAIL PROTECTED]
Sent: Friday, January 05, 2007 1:35 PM
To: Patro, Sumant
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org; Kolli, Neela;
Yang, Bo; Patro, Sumant
Subject: Re: [PATCH] scsi: megaraid_{mm,mbox} init fix for kdump
On Fri, 05 Jan 2007 07:10:09 -0800 Sumant Patro wrote:
Hi,
> ---
>
> Documentation/scsi/ChangeLog.megaraid | 16 ++
> drivers/scsi/megaraid/megaraid_mbox.c | 140 +++-
> drivers/scsi/megaraid/megaraid_mbox.h |4
> 3 files changed, 130 insertions(+), 30 deletions(-)
>
> diff -uprN linux-2.6.orig/drivers/scsi/megaraid/megaraid_mbox.c
linux-2.6.new/drivers/scsi/megaraid/megaraid_mbox.c
> --- linux-2.6.orig/drivers/scsi/megaraid/megaraid_mbox.c
2006-12-28 09:56:04.0 -0800
> +++ linux-2.6.new/drivers/scsi/megaraid/megaraid_mbox.c
2007-01-04 11:22:21.0 -0800
> @@ -3380,6 +3386,84 @@ megaraid_mbox_flush_cache(adapter_t *ada
>
>
> /**
> + * megaraid_mbox_fire_sync_cmd - fire the sync cmd
> + * @param adapter: soft state for the controller
That (above) should just be:
* @adapter: (plus its description; the description there
doesn't seem to agree with its parameter name).
> + *
> + * Clears the pending cmds in FW and reinits its RAID structs */
> +static int megaraid_mbox_fire_sync_cmd(adapter_t *adapter) {
> + mbox_t *mbox;
> + uint8_t raw_mbox[sizeof(mbox_t)];
> + mraid_device_t *raid_dev = ADAP2RAIDDEV(adapter);
> + mbox64_t *mbox64;
> + int status = 0;
> + int i;
> + uint32_t dword;
> +
> + mbox = (mbox_t *)raw_mbox;
> +
> + memset((caddr_t)raw_mbox, 0, sizeof(mbox_t));
> +
> + raw_mbox[0] = 0xFF;
> +
> + mbox64 = raid_dev->mbox64;
> + mbox= raid_dev->mbox;
> +
> + /* Wait until mailbox is free */
> + if (megaraid_busywait_mbox(raid_dev) != 0) {
> + status = 1;
> + goto blocked_mailbox;
> + }
> +
> + /* Copy mailbox data into host structure */
> + memcpy((caddr_t)mbox, (caddr_t)raw_mbox, 16);
> + mbox->cmdid = 0xFE;
> + mbox->busy = 1;
> + mbox->poll = 0;
> + mbox->ack = 0;
> + mbox->numstatus = 0;
> + mbox->status= 0;
> +
> + wmb();
> + WRINDOOR(raid_dev, raid_dev->mbox_dma | 0x1);
> +
> + /* Wait for maximum 1 min for status to post.
> + * If the Firmware SUPPORTS the ABOVE COMMAND,
> + * mbox->cmd will be set to 0
> + * else
> + * the firmware will reject the command with
> + * mbox->numstatus set to 1
> + */
> +
> + i = 0;
> + status = 0;
> + while (!mbox->numstatus && mbox->cmd == 0xFF) {
> + rmb();
> + msleep(1);
> + i++;
> + if (i > 1000 * 60) {
> + status = 1;
> + break;
> + }
> + }
> + if (mbox->numstatus == 1)
> + status = 1; /*cmd not supported*/
> +
> + /* Check for interrupt line */
> + dword = RDOUTDOOR(raid_dev);
> + WROUTDOOR(raid_dev, dword);
> + WRINDOOR(raid_dev,2);
> +
> + return status;
> +
> +blocked_mailbox:
> + con_log(CL_ANN, (KERN_WARNING "megaraid: blocked mailbox\n"));
> + return status;
> +}
> +
> +/**
> * megaraid_mbox_display_scb - display SCB information, mostly debug
purposes
> * @param adapter: controllers' soft state
> * @param scb : SCB to be displayed
I haven't looked at the entire source file, but these extra "param"
words should not be there. kernel-doc syntax is just
@name: description
---
~Randy
-
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: [PATCH] scsi: megaraid_{mm,mbox} init fix for kdump
Hello Randy,
At this time I am not trying to modify the function comment
style of existing megaraid_mbox code. For the new function the
description style is in sync with the preexisting code.
So, I request for the patch to be accepted in its current
submitted form.
Regards,
Sumant
-Original Message-
From: Randy Dunlap [mailto:[EMAIL PROTECTED]
Sent: Friday, January 05, 2007 1:35 PM
To: Patro, Sumant
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org; Kolli, Neela;
Yang, Bo; Patro, Sumant
Subject: Re: [PATCH] scsi: megaraid_{mm,mbox} init fix for kdump
On Fri, 05 Jan 2007 07:10:09 -0800 Sumant Patro wrote:
Hi,
---
Documentation/scsi/ChangeLog.megaraid | 16 ++
drivers/scsi/megaraid/megaraid_mbox.c | 140 +++-
drivers/scsi/megaraid/megaraid_mbox.h |4
3 files changed, 130 insertions(+), 30 deletions(-)
diff -uprN linux-2.6.orig/drivers/scsi/megaraid/megaraid_mbox.c
linux-2.6.new/drivers/scsi/megaraid/megaraid_mbox.c
--- linux-2.6.orig/drivers/scsi/megaraid/megaraid_mbox.c
2006-12-28 09:56:04.0 -0800
+++ linux-2.6.new/drivers/scsi/megaraid/megaraid_mbox.c
2007-01-04 11:22:21.0 -0800
@@ -3380,6 +3386,84 @@ megaraid_mbox_flush_cache(adapter_t *ada
/**
+ * megaraid_mbox_fire_sync_cmd - fire the sync cmd
+ * @param adapter: soft state for the controller
That (above) should just be:
* @adapter: (plus its description; the description there
doesn't seem to agree with its parameter name).
+ *
+ * Clears the pending cmds in FW and reinits its RAID structs */
+static int megaraid_mbox_fire_sync_cmd(adapter_t *adapter) {
+ mbox_t *mbox;
+ uint8_t raw_mbox[sizeof(mbox_t)];
+ mraid_device_t *raid_dev = ADAP2RAIDDEV(adapter);
+ mbox64_t *mbox64;
+ int status = 0;
+ int i;
+ uint32_t dword;
+
+ mbox = (mbox_t *)raw_mbox;
+
+ memset((caddr_t)raw_mbox, 0, sizeof(mbox_t));
+
+ raw_mbox[0] = 0xFF;
+
+ mbox64 = raid_dev-mbox64;
+ mbox= raid_dev-mbox;
+
+ /* Wait until mailbox is free */
+ if (megaraid_busywait_mbox(raid_dev) != 0) {
+ status = 1;
+ goto blocked_mailbox;
+ }
+
+ /* Copy mailbox data into host structure */
+ memcpy((caddr_t)mbox, (caddr_t)raw_mbox, 16);
+ mbox-cmdid = 0xFE;
+ mbox-busy = 1;
+ mbox-poll = 0;
+ mbox-ack = 0;
+ mbox-numstatus = 0;
+ mbox-status= 0;
+
+ wmb();
+ WRINDOOR(raid_dev, raid_dev-mbox_dma | 0x1);
+
+ /* Wait for maximum 1 min for status to post.
+ * If the Firmware SUPPORTS the ABOVE COMMAND,
+ * mbox-cmd will be set to 0
+ * else
+ * the firmware will reject the command with
+ * mbox-numstatus set to 1
+ */
+
+ i = 0;
+ status = 0;
+ while (!mbox-numstatus mbox-cmd == 0xFF) {
+ rmb();
+ msleep(1);
+ i++;
+ if (i 1000 * 60) {
+ status = 1;
+ break;
+ }
+ }
+ if (mbox-numstatus == 1)
+ status = 1; /*cmd not supported*/
+
+ /* Check for interrupt line */
+ dword = RDOUTDOOR(raid_dev);
+ WROUTDOOR(raid_dev, dword);
+ WRINDOOR(raid_dev,2);
+
+ return status;
+
+blocked_mailbox:
+ con_log(CL_ANN, (KERN_WARNING megaraid: blocked mailbox\n));
+ return status;
+}
+
+/**
* megaraid_mbox_display_scb - display SCB information, mostly debug
purposes
* @param adapter: controllers' soft state
* @param scb : SCB to be displayed
I haven't looked at the entire source file, but these extra param
words should not be there. kernel-doc syntax is just
@name: description
---
~Randy
-
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: [Patch] scsi: megaraid_{mm,mbox}: init fix for kdump
Thanks for the review.
I will resubmit the patch.
Regards,
Sumant
-Original Message-
From: Randy Dunlap [mailto:[EMAIL PROTECTED]
Sent: Friday, December 29, 2006 1:38 PM
To: Patro, Sumant
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org; Kolli, Neela;
Yang, Bo; Patro, Sumant
Subject: Re: [Patch] scsi: megaraid_{mm,mbox}: init fix for kdump
On Fri, 29 Dec 2006 08:02:17 -0800 Sumant Patro wrote:
See Documentation/SubmittingPatches:
Please include output of "diffstat -p1 -w70" so that we can easily see
the scope of the changes.
and see Documentation/CodingStyle for comments below:
> diff -uprN linux-2.6.orig/drivers/scsi/megaraid/megaraid_mbox.c
> linux-2.6.new/drivers/scsi/megaraid/megaraid_mbox.c
> --- linux-2.6.orig/drivers/scsi/megaraid/megaraid_mbox.c 2006-12-28
> 09:56:04.0 -0800
> +++ linux-2.6.new/drivers/scsi/megaraid/megaraid_mbox.c 2006-12-29
> +++ 05:31:48.0 -0800
> @@ -779,6 +780,22 @@ megaraid_init_mbox(adapter_t *adapter)
> goto out_release_regions;
> }
>
> + // initialize the mutual exclusion lock for the mailbox
> + spin_lock_init(_dev->mailbox_lock);
Linux uses /*...*/ C89-style comments, not // C99 comments.
> + // allocate memory required for commands
> + if (megaraid_alloc_cmd_packets(adapter) != 0) {
> + goto out_iounmap;
> + }
> +
> + /*
> + * Issue SYNC cmd to flush the pending cmds in the adapter
> + * and initialize its internal state
> + */
> +
> + if (megaraid_mbox_fire_sync_cmd(adapter))
> + con_log(CL_ANN, ("megaraid: sync cmd failed\n"));
> +
> // Product info
> if (megaraid_mbox_product_info(adapter) != 0) {
> - goto out_alloc_cmds;
> + goto out_free_irq;
Don't uses {} braces around 1-statement "blocks".
> @@ -875,7 +883,7 @@ megaraid_init_mbox(adapter_t *adapter)
>* accessed
>*/
> if (megaraid_sysfs_alloc_resources(adapter) != 0) {
> - goto out_alloc_cmds;
> + goto out_free_irq;
Ditto.
> }
>
> // Set the DMA mask to 64-bit. All supported controllers as
capable
> of @@ -3380,6 +3388,86 @@ megaraid_mbox_flush_cache(adapter_t *ada
>
>
> /**
> + * megaraid_mbox_fire_sync_cmd - fire the sync cmd
> + * @param adapter: soft state for the controller
> + */
> +static int
> +megaraid_mbox_fire_sync_cmd(adapter_t *adapter) {
> + mbox_t *mbox;
> + uint8_t raw_mbox[sizeof(mbox_t)];
> + mraid_device_t *raid_dev = ADAP2RAIDDEV(adapter);
> + mbox64_t *mbox64;
> + uint8_t status = 0;
> + int i;
> + uint32_t dword;
> +
> + mbox = (mbox_t *)raw_mbox;
> +
> + memset((caddr_t)raw_mbox, 0, sizeof(mbox_t));
> +
> + raw_mbox[0] = 0xFF;
> +
> + mbox64 = raid_dev->mbox64;
> + mbox= raid_dev->mbox;
> +
> + /*
> + * Wait until mailbox is free
> + */
> + if (megaraid_busywait_mbox(raid_dev) != 0) {
> + status = 1;
> + goto blocked_mailbox;
> + }
> +
> + /*
> + * Copy mailbox data into host structure
> + */
> + memcpy((caddr_t)mbox, (caddr_t)raw_mbox, 16);
> + mbox->cmdid = 0xFE;
> + mbox->busy = 1;
> + mbox->poll = 0;
> + mbox->ack = 0;
> + mbox->numstatus = 0;
> + mbox->status= 0;
> +
> + wmb();
> + WRINDOOR(raid_dev, raid_dev->mbox_dma | 0x1);
> +
> + // wait for maximum 1 min for status to post.
> + // If the Firmware SUPPORTS the ABOVE COMMAND,
> + // mbox->cmd will be set to 0
> + // else
> + // the firmware will reject the command with
> + // mbox->numstatus set to 1
Don't use // comment style. Also, for multi-line comments in Linux,
please use this preferred style:
/*
* This is the preferred style for multi-line
* comments in the Linux kernel source code.
* Please use it consistently.
*
* Description: A column of asterisks on the left side,
* with beginning and ending almost-blank lines.
*/
Thanks.
---
~Randy
-
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: [Patch] scsi: megaraid_{mm,mbox}: init fix for kdump
Thanks for the review.
I will resubmit the patch.
Regards,
Sumant
-Original Message-
From: Randy Dunlap [mailto:[EMAIL PROTECTED]
Sent: Friday, December 29, 2006 1:38 PM
To: Patro, Sumant
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org; Kolli, Neela;
Yang, Bo; Patro, Sumant
Subject: Re: [Patch] scsi: megaraid_{mm,mbox}: init fix for kdump
On Fri, 29 Dec 2006 08:02:17 -0800 Sumant Patro wrote:
See Documentation/SubmittingPatches:
Please include output of diffstat -p1 -w70 so that we can easily see
the scope of the changes.
and see Documentation/CodingStyle for comments below:
diff -uprN linux-2.6.orig/drivers/scsi/megaraid/megaraid_mbox.c
linux-2.6.new/drivers/scsi/megaraid/megaraid_mbox.c
--- linux-2.6.orig/drivers/scsi/megaraid/megaraid_mbox.c 2006-12-28
09:56:04.0 -0800
+++ linux-2.6.new/drivers/scsi/megaraid/megaraid_mbox.c 2006-12-29
+++ 05:31:48.0 -0800
@@ -779,6 +780,22 @@ megaraid_init_mbox(adapter_t *adapter)
goto out_release_regions;
}
+ // initialize the mutual exclusion lock for the mailbox
+ spin_lock_init(raid_dev-mailbox_lock);
Linux uses /*...*/ C89-style comments, not // C99 comments.
+ // allocate memory required for commands
+ if (megaraid_alloc_cmd_packets(adapter) != 0) {
+ goto out_iounmap;
+ }
+
+ /*
+ * Issue SYNC cmd to flush the pending cmds in the adapter
+ * and initialize its internal state
+ */
+
+ if (megaraid_mbox_fire_sync_cmd(adapter))
+ con_log(CL_ANN, (megaraid: sync cmd failed\n));
+
// Product info
if (megaraid_mbox_product_info(adapter) != 0) {
- goto out_alloc_cmds;
+ goto out_free_irq;
Don't uses {} braces around 1-statement blocks.
@@ -875,7 +883,7 @@ megaraid_init_mbox(adapter_t *adapter)
* accessed
*/
if (megaraid_sysfs_alloc_resources(adapter) != 0) {
- goto out_alloc_cmds;
+ goto out_free_irq;
Ditto.
}
// Set the DMA mask to 64-bit. All supported controllers as
capable
of @@ -3380,6 +3388,86 @@ megaraid_mbox_flush_cache(adapter_t *ada
/**
+ * megaraid_mbox_fire_sync_cmd - fire the sync cmd
+ * @param adapter: soft state for the controller
+ */
+static int
+megaraid_mbox_fire_sync_cmd(adapter_t *adapter) {
+ mbox_t *mbox;
+ uint8_t raw_mbox[sizeof(mbox_t)];
+ mraid_device_t *raid_dev = ADAP2RAIDDEV(adapter);
+ mbox64_t *mbox64;
+ uint8_t status = 0;
+ int i;
+ uint32_t dword;
+
+ mbox = (mbox_t *)raw_mbox;
+
+ memset((caddr_t)raw_mbox, 0, sizeof(mbox_t));
+
+ raw_mbox[0] = 0xFF;
+
+ mbox64 = raid_dev-mbox64;
+ mbox= raid_dev-mbox;
+
+ /*
+ * Wait until mailbox is free
+ */
+ if (megaraid_busywait_mbox(raid_dev) != 0) {
+ status = 1;
+ goto blocked_mailbox;
+ }
+
+ /*
+ * Copy mailbox data into host structure
+ */
+ memcpy((caddr_t)mbox, (caddr_t)raw_mbox, 16);
+ mbox-cmdid = 0xFE;
+ mbox-busy = 1;
+ mbox-poll = 0;
+ mbox-ack = 0;
+ mbox-numstatus = 0;
+ mbox-status= 0;
+
+ wmb();
+ WRINDOOR(raid_dev, raid_dev-mbox_dma | 0x1);
+
+ // wait for maximum 1 min for status to post.
+ // If the Firmware SUPPORTS the ABOVE COMMAND,
+ // mbox-cmd will be set to 0
+ // else
+ // the firmware will reject the command with
+ // mbox-numstatus set to 1
Don't use // comment style. Also, for multi-line comments in Linux,
please use this preferred style:
/*
* This is the preferred style for multi-line
* comments in the Linux kernel source code.
* Please use it consistently.
*
* Description: A column of asterisks on the left side,
* with beginning and ending almost-blank lines.
*/
Thanks.
---
~Randy
-
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/
