RE: [patch 05/13] MegaRAID driver management char device moved tomisc
James, I acked this patch on 11/28. We are fine with the change proposed. Regards, Sumant -Original Message- From: James Bottomley [mailto:[EMAIL PROTECTED] Sent: Thursday, February 07, 2008 4:41 PM To: [EMAIL PROTECTED] Cc: linux-scsi@vger.kernel.org; [EMAIL PROTECTED]; Kolli, Neela; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Patro, Sumant Subject: Re: [patch 05/13] MegaRAID driver management char device moved tomisc On Mon, 2008-02-04 at 23:53 -0800, [EMAIL PROTECTED] wrote: From: Thomas Horsten [EMAIL PROTECTED] The MegaRAID driver's common management module (megaraid_mm.c) creates a char device used by the management tool megarc from LSI Logic (and possibly other management tools). In 2.6 with udev, this device doesn't get created because it is not registered in sysfs. I first fixed this by registering a class megaraid_mm, but realized that this should probably be moved to misc devices, instead of taking up a char major. This is because only 1 device is used, even if there are multiple adapters - the minor is never used (the adapter info is in the ioctl block sent to the driver, not detected based on the minor number as one might think). So it is a complete waste to have an entire major taken by this. So it now uses a misc device which I named megadev0 (the name that megarc expects), and has a dynamic minor (previoulsy a dynamic major was used). I have tested this on my own system with the megarc tool, and it works just as fine as before (only now the device gets created correctly by udev). Cc: [EMAIL PROTECTED] Cc: Neela Syam Kolli [EMAIL PROTECTED] Cc: Ju, Seokmann [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Neela and Sekomann or Sumant, can I ping on this ... I've no idea what this will do to the raid management tools, so I really need someone to sign off on this. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] megaraid: fix section mismatch
Ack.
--Sumant
-Original Message-
From: Randy Dunlap [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 10, 2008 2:33 PM
To: DL-MegaRAID Linux; scsi
Cc: jejb; akpm; samr
Subject: [PATCH] megaraid: fix section mismatch
From: Randy Dunlap [EMAIL PROTECTED]
Change megaraid_pci_driver_g variable name so that it matches the
modpost whitelist that allows pointers to init text/data.
WARNING: vmlinux.o(.data+0x1a8e30): Section mismatch: reference to
.init.text:megaraid_probe_one (between 'megaraid_pci_driver_g' and
'class_device_attr_megaraid_mbox_app_hndl')
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
drivers/scsi/megaraid/megaraid_mbox.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.24-rc7-git1.orig/drivers/scsi/megaraid/megaraid_mbox.c
+++ linux-2.6.24-rc7-git1/drivers/scsi/megaraid/megaraid_mbox.c
@@ -300,7 +300,7 @@ static struct pci_device_id pci_id_table
MODULE_DEVICE_TABLE(pci, pci_id_table_g);
-static struct pci_driver megaraid_pci_driver_g = {
+static struct pci_driver megaraid_pci_driver = {
.name = megaraid,
.id_table = pci_id_table_g,
.probe = megaraid_probe_one,
@@ -394,7 +394,7 @@ megaraid_init(void)
// register as a PCI hot-plug driver module
- rval = pci_register_driver(megaraid_pci_driver_g);
+ rval = pci_register_driver(megaraid_pci_driver);
if (rval 0) {
con_log(CL_ANN, (KERN_WARNING
megaraid: could not register hotplug
support.\n)); @@ -415,7 +415,7 @@ megaraid_exit(void)
con_log(CL_DLEVEL1, (KERN_NOTICE megaraid: unloading
framework\n));
// unregister as PCI hotplug driver
- pci_unregister_driver(megaraid_pci_driver_g);
+ pci_unregister_driver(megaraid_pci_driver);
return;
}
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [2.6 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: linux-scsi@vger.kernel.org; [EMAIL PROTECTED]
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-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 23/23] Dell CERC support for megaraid_mbox
Hannes,
Thanks for the patch and the details on the issue.
With this patch we will be blocking a feature that is now being
used by the users with the legacy driver. The applications may still
allow random delete and that could create more issue if we just block
it/change the required behavior from the driver. As now we know the
possible reason on the issue, I will see if I can come up with a
implementation that will allow the random delete feature and still make
the LDs available.
So, for now I don't want this patch to be added. Will submit a
separate patch to address the issue.
Regards,
Sumant
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 21, 2007 3:13 PM
To: [EMAIL PROTECTED]
Cc: linux-scsi@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Patro, Sumant
Subject: [patch 23/23] Dell CERC support for megaraid_mbox
From: Hannes Reinecke [EMAIL PROTECTED]
Newer Dell CERC firmware (= 6.62) implement a random deletion handling
compatible with the legacy megaraid driver. The legacy handling shifted
the target ID by 0x80 only for I/O commands (READ/WRITE/etc), whereas
megaraid_mbox shifts the target ID always if random deletion is
supported.
The resulted in megaraid_mbox sending an INQUIRY to the wrong channel,
and not finding any devices, obviously.
So we disable the random deletion support if the offending firmware is
found.
Addresses http://bugzilla.kernel.org/show_bug.cgi?id=6695
Signed-off-by: Hannes Reinecke [EMAIL PROTECTED]
Cc: Patro, Sumant [EMAIL PROTECTED]
Cc: James Bottomley [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/scsi/megaraid/megaraid_mbox.c | 17 +
drivers/scsi/megaraid/megaraid_mbox.h |1 +
2 files changed, 18 insertions(+)
diff -puN
drivers/scsi/megaraid/megaraid_mbox.c~dell-cerc-support-for-megaraid_mbo
x drivers/scsi/megaraid/megaraid_mbox.c
---
a/drivers/scsi/megaraid/megaraid_mbox.c~dell-cerc-support-for-megaraid_m
box
+++ a/drivers/scsi/megaraid/megaraid_mbox.c
@@ -3169,6 +3169,23 @@ megaraid_mbox_support_random_del(adapter
uint8_t raw_mbox[sizeof(mbox_t)];
int rval;
+ /*
+* Newer firmware on Dell CERC expect a different
+* random deletion handling, so disable it.
+*/
+ if (adapter-pdev-vendor == PCI_VENDOR_ID_AMI
+ adapter-pdev-device == PCI_DEVICE_ID_AMI_MEGARAID3
+ adapter-pdev-subsystem_vendor == PCI_VENDOR_ID_DELL
+ adapter-pdev-subsystem_device ==
PCI_SUBSYS_ID_CERC_ATA100_4CH
+ (adapter-fw_version[0] '6' ||
+(adapter-fw_version[0] == '6'
+ adapter-fw_version[2] '6') ||
+(adapter-fw_version[0] == '6'
+ adapter-fw_version[2] == '6'
+ adapter-fw_version[3] '1'))) {
+ con_log(CL_DLEVEL1, (megaraid: disable random
deletion\n));
+ return 0;
+ }
mbox = (mbox_t *)raw_mbox;
diff -puN
drivers/scsi/megaraid/megaraid_mbox.h~dell-cerc-support-for-megaraid_mbo
x drivers/scsi/megaraid/megaraid_mbox.h
---
a/drivers/scsi/megaraid/megaraid_mbox.h~dell-cerc-support-for-megaraid_m
box
+++ a/drivers/scsi/megaraid/megaraid_mbox.h
@@ -88,6 +88,7 @@
#define PCI_SUBSYS_ID_PERC3_QC 0x0471
#define PCI_SUBSYS_ID_PERC3_DC 0x0493
#define PCI_SUBSYS_ID_PERC3_SC 0x0475
+#define PCI_SUBSYS_ID_CERC_ATA100_4CH 0x0511
#define MBOX_MAX_SCSI_CMDS 128 // number of cmds reserved for
kernel
_
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 12/23] MegaRAID driver management char device moved to misc
ACK.
Thanks Thomas.
Regards,
Sumant
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, November 21, 2007 3:12 PM
To: [EMAIL PROTECTED]
Cc: linux-scsi@vger.kernel.org; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Kolli, Neela; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: [patch 12/23] MegaRAID driver management char device moved to
misc
From: Thomas Horsten [EMAIL PROTECTED]
The MegaRAID driver's common management module (megaraid_mm.c) creates a
char device used by the management tool megarc from LSI Logic (and
possibly other management tools).
In 2.6 with udev, this device doesn't get created because it is not
registered in sysfs.
I first fixed this by registering a class megaraid_mm, but realized
that this should probably be moved to misc devices, instead of taking up
a char major. This is because only 1 device is used, even if there are
multiple adapters - the minor is never used (the adapter info is in the
ioctl block sent to the driver, not detected based on the minor number
as one might think). So it is a complete waste to have an entire major
taken by this.
So it now uses a misc device which I named megadev0 (the name that
megarc expects), and has a dynamic minor (previoulsy a dynamic major was
used).
I have tested this on my own system with the megarc tool, and it works
just as fine as before (only now the device gets created correctly by
udev).
Cc: [EMAIL PROTECTED]
Cc: Neela Syam Kolli [EMAIL PROTECTED]
Cc: Ju, Seokmann [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/scsi/megaraid/megaraid_mm.c | 20 +---
drivers/scsi/megaraid/megaraid_mm.h |1 +
2 files changed, 14 insertions(+), 7 deletions(-)
diff -puN
drivers/scsi/megaraid/megaraid_mm.c~megaraid-driver-management-char-devi
ce-moved-to-misc drivers/scsi/megaraid/megaraid_mm.c
---
a/drivers/scsi/megaraid/megaraid_mm.c~megaraid-driver-management-char-de
vice-moved-to-misc
+++ a/drivers/scsi/megaraid/megaraid_mm.c
@@ -59,7 +59,6 @@ EXPORT_SYMBOL(mraid_mm_register_adp);
EXPORT_SYMBOL(mraid_mm_unregister_adp);
EXPORT_SYMBOL(mraid_mm_adapter_app_handle);
-static int majorno;
static uint32_t drvr_ver = 0x02200207;
static int adapters_count_g;
@@ -76,6 +75,12 @@ static const struct file_operations lsi_
.owner = THIS_MODULE,
};
+static struct miscdevice megaraid_mm_dev = {
+ .minor = MISC_DYNAMIC_MINOR,
+ .name = megadev0,
+ .fops = lsi_fops,
+};
+
/**
* mraid_mm_open - open routine for char node interface
* @inode : unused
@@ -1184,15 +1189,16 @@ mraid_mm_teardown_dma_pools(mraid_mmadp_
static int __init
mraid_mm_init(void)
{
+ int err;
+
// Announce the driver version
con_log(CL_ANN, (KERN_INFO megaraid cmm: %s %s\n,
LSI_COMMON_MOD_VERSION, LSI_COMMON_MOD_EXT_VERSION));
- majorno = register_chrdev(0, megadev, lsi_fops);
-
- if (majorno 0) {
- con_log(CL_ANN, (megaraid cmm: cannot get major\n));
- return majorno;
+ err = misc_register(megaraid_mm_dev);
+ if (err 0) {
+ con_log(CL_ANN, (megaraid cmm: cannot register misc
device\n));
+ return err;
}
init_waitqueue_head(wait_q);
@@ -1230,7 +1236,7 @@ mraid_mm_exit(void) {
con_log(CL_DLEVEL1 , (exiting common mod\n));
- unregister_chrdev(majorno, megadev);
+ misc_deregister(megaraid_mm_dev);
}
module_init(mraid_mm_init);
diff -puN
drivers/scsi/megaraid/megaraid_mm.h~megaraid-driver-management-char-devi
ce-moved-to-misc drivers/scsi/megaraid/megaraid_mm.h
---
a/drivers/scsi/megaraid/megaraid_mm.h~megaraid-driver-management-char-de
vice-moved-to-misc
+++ a/drivers/scsi/megaraid/megaraid_mm.h
@@ -22,6 +22,7 @@
#include linux/moduleparam.h
#include linux/pci.h
#include linux/list.h
+#include linux/miscdevice.h
#include mbox_defs.h
#include megaraid_ioctl.h
_
-
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-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: slow after upgrade to CentOS 5 (RHEL5)
The problem is not apparent from the driver messages. There are no error messages from the driver per se. What driver version was used in CentOS 4? Regards, Sumant -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Bottomley Sent: Sunday, October 28, 2007 7:27 AM To: Anthony Ewell Cc: linux-scsi Subject: Re: slow after upgrade to CentOS 5 (RHEL5) On Sat, 2007-10-27 at 13:21 -0700, Anthony Ewell wrote: James Bottomley wrote: On Wed, 2007-10-24 at 18:04 -0700, Anthony Ewell wrote: Hi All, If you all would not mind a post from the general public Linux user, after doing a complete disk wipe of CentOS 4 and installing CentOS5, my system is preceived to be 3 times slower. To troubleshooting this, I made a post on CentOS's bugzilla: http://bugs.centos.org/view.php?id=2382 Would some of the experts on this group mind looking at the bug to evaluate the possibility that it is being caused by the underlying scsi driver? The post contains a dmesg from Computer C. (Yes, I am getting a bit desperate.) There's still too little information in the bug report to tell much of anything. The dmesg doesn't indicate any anomaly with the megaraid (although the LSI people might be able to tell better). However, it also doesn't contain a trace of the tape drive. Best guess would be a slow down in the megaraid driver. Can you try doing a speed test on it? (hdparm -t should suffice). James Hi James, The other guy reporting the problem http://www.centos.org/modules/newbb/viewtopic.php?topic_id=10659start =0#forumpost34209 is not using a MegaRAID card. He is using 3ware9508 Raid Controllers. He is also using a different processor (amd vs xeon) and a different chipset (Intel Greenwood vs nVidia) I also spoke to Neela Kolli (Mega RAID maintainer) and he said he'd never heard of the problem. Here are some tests (including dhparm) that I sent to Neela (he never wrote back). I have also checked with Stellen over at the dump list and he has not seen the problem (yet). The problem occurs when backing up to a two different types of tape drives and to an eSata drive. When I am running a dump on computer C, gnome-system-monitor shows my two cores running at only about 10 to 20% and switching back and forth (one at 0% the other at 20% for about 5 seconds, then switching positions) On Computer C (Cent OS 5), when typing in Word Pro (a windows word processor) in Parallels, I can watch myself type. Computer B (CentOS 4.4, now 4.5) has the same version of Parallels installed on it (Parallels-2.2.2112-lin.i386) that computer C (CentOS 5) has. The perceived speed difference is about a factor of three (you can not watch yourself type). All the Low Level test I run seem to come out the same between Cent OS 4.4 and 5. Very frustrating! It is almost like some system monitor component is looking at everything and slowing things down. If this was Windows, I'd go straight to the Anti Virus as the culprit. (Does SE Linux do such things?) Are there any performance tests I can run for you? Thank you for letting me ramble, this problem is really frustrating. I am afraid to any additional CentOS5 server out there and CentOS 4.x is so terribly out of date. -T ~~ Tests I sent to Neela: CentOS 5 (2.6.18-8.1.8.el5, Sata150-4): #grep -i bogomips /var/log/dmesg Calibrating delay using timer specific routine.. 4001.91 BogoMIPS (lpj=2000959) Calibrating delay using timer specific routine.. 3999.58 BogoMIPS (lpj=1999791) Total of 2 processors activated (8001.50 BogoMIPS). #/sbin/hdparm -t /dev/sda /dev/sda: Timing buffered disk reads: 236 MB in 3.01 seconds = 78.53 MB/sec #/sbin/hdparm -t /dev/sdb /dev/sdb: Timing buffered disk reads: 182 MB in 3.01 seconds = 60.37 MB/sec ~~ CentOS 4.4 (linux rescue 2.6.9-42.EL, IDE): #cat /proc/cpuinfo bogomips : 4002.92 #/sbin/hdparm -t /dev/sda /dev/sda: Timing buffered disk reads: 216 MB in 3.01 seconds = 71.87 MB/sec #/sbin/hdparm -t /dev/sdb /dev/sdb: Timing buffered disk reads: 184 MB in 3.01 seconds = 61.18 MB/sec That pretty much shows, if anything, that transfer speed improved from .9 to .18. ~~ CentOS 5 (2.6.18-8.1.3.el5, Sata300-4): #grep -i bogomips /var/log/dmesg Calibrating delay using timer specific routine.. 4001.92 BogoMIPS (lpj=2000960) Calibrating delay using timer specific routine.. 3999.58 BogoMIPS (lpj=1999794) Total of 2 processors activated (8001.50 BogoMIPS). #/sbin/hdparm -t /dev/sda /dev/sda: Timing buffered disk reads: 214 MB in 3.02 seconds = 70.86 MB/sec ~~ CentOS 5 (2.6.18-10.1.3.el5,
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];
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Patro, Sumant; DL-MegaRAID
Linux; linux-scsi@vger.kernel.org
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-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] [MEGARAID_SAS]: Use pr_info
Hello Arnaldo,
Throughout the megaraid_sas driver code there are printk's with
appropriate flags (that includes KERN_INFO). What is the incentive to
change printk with KERN_INFO to pr_info?
Regards,
Sumant
-Original Message-
From: Arnaldo Carvalho de Melo [mailto:[EMAIL PROTECTED] On Behalf
Of Arnaldo Carvalho de Melo
Sent: Wednesday, August 08, 2007 4:15 PM
To: DL-MegaRAID Linux
Cc: linux-scsi@vger.kernel.org; James Bottomley
Subject: [PATCH] [MEGARAID_SAS]: Use pr_info
Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
---
drivers/scsi/megaraid/megaraid_sas.c | 14 ++
1 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas.c
b/drivers/scsi/megaraid/megaraid_sas.c
index 59099da..4a8cf06 100644
--- a/drivers/scsi/megaraid/megaraid_sas.c
+++ b/drivers/scsi/megaraid/megaraid_sas.c
@@ -1341,8 +1341,7 @@ megasas_transition_to_ready(struct
megasas_instance* instance)
fw_state =
instance-instancet-read_fw_status_reg(instance-reg_set)
MFI_STATE_MASK;
if (fw_state != MFI_STATE_READY)
- printk(KERN_INFO megasas: Waiting for FW to come to
ready
- state\n);
+ pr_info(megasas: Waiting for FW to come to ready
state\n);
while (fw_state != MFI_STATE_READY) {
@@ -1444,7 +1443,7 @@ megasas_transition_to_ready(struct
megasas_instance* instance)
return -ENODEV;
}
};
- printk(KERN_INFO megasas: FW now in Ready state\n);
+ pr_info(megasas: FW now in Ready state\n);
return 0;
}
@@ -2277,9 +2276,9 @@ megasas_probe_one(struct pci_dev *pdev, const
struct pci_device_id *id)
/*
* Announce PCI information
*/
- printk(KERN_INFO megasas: %#4.04x:%#4.04x:%#4.04x:%#4.04x: ,
- pdev-vendor, pdev-device, pdev-subsystem_vendor,
- pdev-subsystem_device);
+ pr_info(megasas: %#4.04x:%#4.04x:%#4.04x:%#4.04x: ,
+ pdev-vendor, pdev-device, pdev-subsystem_vendor,
+ pdev-subsystem_device);
printk(bus %d:slot %d:func %d\n,
pdev-bus-number, PCI_SLOT(pdev-devfn),
PCI_FUNC(pdev-devfn)); @@ -3030,8 +3029,7 @@ static int __init
megasas_init(void)
/*
* Announce driver version and other information
*/
- printk(KERN_INFO megasas: %s %s\n, MEGASAS_VERSION,
- MEGASAS_EXT_VERSION);
+ pr_info(megasas: %s %s\n, MEGASAS_VERSION,
MEGASAS_EXT_VERSION);
/*
* Register character device node
--
1.5.2.2
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 24/30] drivers/scsi/megaraid.c: kmalloc + memset conversion to kzalloc
ACK. --Sumant -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, August 10, 2007 2:51 PM To: [EMAIL PROTECTED] Cc: linux-scsi@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [patch 24/30] drivers/scsi/megaraid.c: kmalloc + memset conversion to kzalloc From: Mariusz Kozlowski [EMAIL PROTECTED] This patch does kmalloc + memset conversion to kzalloc and adds missing check for kzalloc return value. drivers/scsi/megaraid.c | 116109 - 116094 (-15 bytes) drivers/scsi/megaraid.o | 257872 - 257772 (-100 bytes) Signed-off-by: Mariusz Kozlowski [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/scsi/megaraid.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff -puN drivers/scsi/megaraid.c~drivers-scsi-megaraidc-kmalloc-memset-conversion -to-kzalloc drivers/scsi/megaraid.c --- a/drivers/scsi/megaraid.c~drivers-scsi-megaraidc-kmalloc-memset-conversi on-to-kzalloc +++ a/drivers/scsi/megaraid.c @@ -4408,8 +4408,10 @@ mega_internal_command(adapter_t *adapter scmd = adapter-int_scmd; memset(scmd, 0, sizeof(Scsi_Cmnd)); - sdev = kmalloc(sizeof(struct scsi_device), GFP_KERNEL); - memset(sdev, 0, sizeof(struct scsi_device)); + sdev = kzalloc(sizeof(struct scsi_device), GFP_KERNEL); + if (!sdev) + return -ENOMEM; + scmd-device = sdev; scmd-device-host = adapter-host; _ - 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-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 10/30] megaraid: add CERC_ATA100 support
-Original Message- From: Andrew Morton [mailto:[EMAIL PROTECTED] Sent: Friday, August 10, 2007 3:36 PM To: Patro, Sumant Cc: [EMAIL PROTECTED]; linux-scsi@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Kolli, Neela; Yang, Bo Subject: Re: [patch 10/30] megaraid: add CERC_ATA100 support On Fri, 10 Aug 2007 16:20:54 -0600 Patro, Sumant [EMAIL PROTECTED] wrote: ID being added is already supported in megaraid_mbox driver. umm, why should that cause us to avoid supporting it in the old driver? With overlapping ids it will be indeterminate which one (megaraid legacy/mbox) claims the device. All overlapping IDS were removed from megaraid legacy/megaraid_mbox driver about 2 years back. --Sumant - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 17/17] use mutex instead of semaphore in Megaraid Mailbox driver
Ack.
--Sumant
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, July 09, 2007 12:00 PM
To: [EMAIL PROTECTED]
Cc: linux-scsi@vger.kernel.org; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Patro, Sumant
Subject: [patch 17/17] use mutex instead of semaphore in Megaraid
Mailbox driver
From: Matthias Kaehlcke [EMAIL PROTECTED]
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]
Cc: Patro, Sumant [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/scsi/megaraid/mega_common.h |1 +
drivers/scsi/megaraid/megaraid_mbox.c |6 +++---
drivers/scsi/megaraid/megaraid_mbox.h |4 ++--
3 files changed, 6 insertions(+), 5 deletions(-)
diff -puN
drivers/scsi/megaraid/mega_common.h~use-mutex-instead-of-semaphore-in-me
garaid-mailbox-driver drivers/scsi/megaraid/mega_common.h
---
a/drivers/scsi/megaraid/mega_common.h~use-mutex-instead-of-semaphore-in-
megaraid-mailbox-driver
+++ a/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 -puN
drivers/scsi/megaraid/megaraid_mbox.c~use-mutex-instead-of-semaphore-in-
megaraid-mailbox-driver drivers/scsi/megaraid/megaraid_mbox.c
---
a/drivers/scsi/megaraid/megaraid_mbox.c~use-mutex-instead-of-semaphore-i
n-megaraid-mailbox-driver
+++ a/drivers/scsi/megaraid/megaraid_mbox.c
@@ -3880,7 +3880,7 @@ megaraid_sysfs_alloc_resources(adapter_t
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);
@@ -3981,7 +3981,7 @@ megaraid_sysfs_get_ldmap(adapter_t *adap
/*
* 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;
@@ -4057,7 +4057,7 @@ megaraid_sysfs_get_ldmap(adapter_t *adap
del_timer_sync(timerp);
- up(raid_dev-sysfs_sem);
+ mutex_unlock(raid_dev-sysfs_mtx);
return rval;
}
diff -puN
drivers/scsi/megaraid/megaraid_mbox.h~use-mutex-instead-of-semaphore-in-
megaraid-mailbox-driver drivers/scsi/megaraid/megaraid_mbox.h
---
a/drivers/scsi/megaraid/megaraid_mbox.h~use-mutex-instead-of-semaphore-i
n-megaraid-mailbox-driver
+++ a/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;
_
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 1/1] scsi: cover up bugs^W^W^WFix up compiler warnings in megaraid driver
Hello Andrew, The email-id [EMAIL PROTECTED] is the alias for driver developers for MegaRAID product. This id includes my name. Recently I submitted patch to update the MAINTAINERS to add this id. Regards, Sumant -Original Message- From: Andrew Morton [mailto:[EMAIL PROTECTED] Sent: Friday, May 25, 2007 2:46 PM To: Patro, Sumant Cc: [EMAIL PROTECTED]; linux-scsi@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: [patch 1/1] scsi: cover up bugs^W^W^WFix up compiler warnings in megaraid driver On Fri, 25 May 2007 14:28:19 -0600 Patro, Sumant [EMAIL PROTECTED] wrote: Ack. Thanks. While we're here... box:/usr/src/25 grep -i lsi MAINTAINERS LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI) M: [EMAIL PROTECTED] M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://www.lsilogic.com/support LSILOGIC/SYMBIOS/NCR 53C8XX and 53C1010 PCI-SCSI drivers W: http://megaraid.lsilogic.com USB KAWASAKI LSI DRIVER M: [EMAIL PROTECTED] box:/usr/src/25 grep -i sumant MAINTAINERS box:/usr/src/25 Could I ask that you review the MAINTAINERS file and ensure that all appropriate lsil developers are appropriately mentioned and that all drivers which lsil look after have the appropriate entries? Thanks. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 1/1] scsi: cover up bugs^W^W^WFix up compiler warnings in megaraid driver
Ack.
--Sumant
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, May 23, 2007 4:12 PM
To: [EMAIL PROTECTED]
Cc: linux-scsi@vger.kernel.org; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: [patch 1/1] scsi: cover up bugs^W^W^WFix up compiler warnings
in megaraid driver
From: Martin Bligh [EMAIL PROTECTED]
Fix up compiler warnings in megaraid driver
Signed-off-by: Martin J. Bligh [EMAIL PROTECTED]
Cc: James Bottomley [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/scsi/megaraid.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff -puN
drivers/scsi/megaraid.c~scsi-cover-up-bugs-fix-up-compiler-warnings-in-m
egaraid-driver drivers/scsi/megaraid.c
---
a/drivers/scsi/megaraid.c~scsi-cover-up-bugs-fix-up-compiler-warnings-in
-megaraid-driver
+++ a/drivers/scsi/megaraid.c
@@ -3571,7 +3571,7 @@ megadev_ioctl(struct inode *inode, struc
/*
* The user passthru structure
*/
- upthru = (mega_passthru __user
*)MBOX(uioc)-xferaddr;
+ upthru = (mega_passthru __user *)(unsigned
long)MBOX(uioc)-xferaddr;
/*
* Copy in the user passthru here.
@@ -3623,7 +3623,7 @@ megadev_ioctl(struct inode *inode, struc
/*
* Get the user data
*/
- if( copy_from_user(data, (char __user
*)uxferaddr,
+ if( copy_from_user(data, (char __user
*)(unsigned long) uxferaddr,
pthru-dataxferlen) ) {
rval = (-EFAULT);
goto freemem_and_return;
@@ -3649,7 +3649,7 @@ megadev_ioctl(struct inode *inode, struc
* Is data going up-stream
*/
if( pthru-dataxferlen (uioc.flags UIOC_RD)
) {
- if( copy_to_user((char __user
*)uxferaddr, data,
+ if( copy_to_user((char __user
*)(unsigned long) uxferaddr, data,
pthru-dataxferlen) ) {
rval = (-EFAULT);
}
@@ -3702,7 +3702,7 @@ freemem_and_return:
/*
* Get the user data
*/
- if( copy_from_user(data, (char __user
*)uxferaddr,
+ if( copy_from_user(data, (char __user
*)(unsigned long) uxferaddr,
uioc.xferlen) )
{
pci_free_consistent(pdev,
@@ -3742,7 +3742,7 @@ freemem_and_return:
* Is data going up-stream
*/
if( uioc.xferlen (uioc.flags UIOC_RD) ) {
- if( copy_to_user((char __user
*)uxferaddr, data,
+ if( copy_to_user((char __user
*)(unsigned long) uxferaddr, data,
uioc.xferlen) )
{
rval = (-EFAULT);
_
-
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-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] scsi: megaraid_sas - intercepts cmd timeout andthrottle io
Sorry I had missed those comments.
Will address those and resubmit.
Regards,
Sumant
-Original Message-
From: James Bottomley [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 10, 2007 12:24 PM
To: Patro, Sumant
Cc: [EMAIL PROTECTED]; linux-scsi@vger.kernel.org; Kolli, Neela; Yang, Bo
Subject: Re: [PATCH] scsi: megaraid_sas - intercepts cmd timeout
andthrottle io
On Thu, 2007-05-10 at 07:01 -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.
Also removed reserved fields from struct megasas_instance.
And the rest of the comments?
This is the cut out of all the ones I made, I think:
+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?
+ 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.
- if (cmd-scmd) {
+ if (cmd-scmd)
cmd-scmd-SCp.ptr = (char *)0;
That's NULL, ordinarily ...
James
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 08/30] drivers/scsi/megaraid.c: Replacing yield() with a better alternative
Ack.
Thanks.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, April 26, 2007 12:35 AM
To: [EMAIL PROTECTED]
Cc: linux-scsi@vger.kernel.org; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: [patch 08/30] drivers/scsi/megaraid.c: Replacing yield() with a
better alternative
From: Amol Lad [EMAIL PROTECTED]
For this driver cond_resched() seems to be a better alternative
Signed-off-by: Amol Lad [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/scsi/megaraid.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff -puN
drivers/scsi/megaraid.c~drivers-scsi-megaraidc-replacing-yield-with-a
drivers/scsi/megaraid.c
---
a/drivers/scsi/megaraid.c~drivers-scsi-megaraidc-replacing-yield-with-a
+++ a/drivers/scsi/megaraid.c
@@ -1754,7 +1754,8 @@ __mega_busywait_mbox (adapter_t *adapter
for (counter = 0; counter 1; counter++) {
if (!mbox-m_in.busy)
return 0;
- udelay(100); yield();
+ udelay(100);
+ cond_resched();
}
return -1; /* give up after 1 second */
}
_
-
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-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 04/30] megaraid: fix warnings when CONFIG_PROC_FS=n
Ack.
Thanks,
Sumant
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, April 26, 2007 12:35 AM
To: [EMAIL PROTECTED]
Cc: linux-scsi@vger.kernel.org; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [patch 04/30] megaraid: fix warnings when CONFIG_PROC_FS=n
From: walter harms [EMAIL PROTECTED]
Signed-off-by: walter harms [EMAIL PROTECTED]
Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED]
Cc: Adrian Bunk [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/scsi/megaraid.c | 17 +++--
drivers/scsi/megaraid.h |4 ++--
2 files changed, 13 insertions(+), 8 deletions(-)
diff -puN
drivers/scsi/megaraid.c~megaraid-fix-warnings-when-config_proc_fs=n
drivers/scsi/megaraid.c
---
a/drivers/scsi/megaraid.c~megaraid-fix-warnings-when-config_proc_fs=n
+++ a/drivers/scsi/megaraid.c
@@ -3177,7 +3177,10 @@ proc_rdrv(adapter_t *adapter, char *page
return len;
}
-
+#else
+static inline void mega_create_proc_entry(int index, struct
proc_dir_entry *parent)
+{
+}
#endif
@@ -4342,7 +4345,7 @@ mega_support_cluster(adapter_t *adapter)
return 0;
}
-
+#ifdef CONFIG_PROC_FS
/**
* mega_adapinq()
* @adapter - pointer to our soft state
@@ -4447,7 +4450,7 @@ mega_internal_dev_inquiry(adapter_t *ada
return rval;
}
-
+#endif
/**
* mega_internal_command()
@@ -4965,7 +4968,6 @@ megaraid_remove_one(struct pci_dev *pdev
{
struct Scsi_Host *host = pci_get_drvdata(pdev);
adapter_t *adapter = (adapter_t *)host-hostdata;
- charbuf[12] = { 0 };
scsi_remove_host(host);
@@ -5011,8 +5013,11 @@ megaraid_remove_one(struct pci_dev *pdev
remove_proc_entry(raiddrives-30-39,
adapter-controller_proc_dir_entry);
#endif
- sprintf(buf, hba%d, adapter-host-host_no);
- remove_proc_entry(buf, mega_proc_dir_entry);
+ {
+ charbuf[12] = { 0 };
+ sprintf(buf, hba%d, adapter-host-host_no);
+ remove_proc_entry(buf, mega_proc_dir_entry);
+ }
}
#endif
diff -puN
drivers/scsi/megaraid.h~megaraid-fix-warnings-when-config_proc_fs=n
drivers/scsi/megaraid.h
---
a/drivers/scsi/megaraid.h~megaraid-fix-warnings-when-config_proc_fs=n
+++ a/drivers/scsi/megaraid.h
@@ -1002,7 +1002,6 @@ static int megaraid_reset(Scsi_Cmnd *);
static int megaraid_abort_and_reset(adapter_t *, Scsi_Cmnd *, int);
static int megaraid_biosparam(struct scsi_device *, struct block_device
*,
sector_t, int []);
-static int mega_print_inquiry(char *, char *);
static int mega_build_sglist (adapter_t *adapter, scb_t *scb,
u32 *buffer, u32 *length);
@@ -1024,6 +1023,7 @@ static int mega_init_scb (adapter_t *);
static int mega_is_bios_enabled (adapter_t *);
#ifdef CONFIG_PROC_FS
+static int mega_print_inquiry(char *, char *);
static void mega_create_proc_entry(int, struct proc_dir_entry *);
static int proc_read_config(char *, char **, off_t, int, int *, void
*);
static int proc_read_stat(char *, char **, off_t, int, int *, void *);
@@ -1040,10 +1040,10 @@ static int proc_rdrv_20(char *, char **,
static int proc_rdrv_30(char *, char **, off_t, int, int *, void *);
static int proc_rdrv_40(char *, char **, off_t, int, int *, void *);
static int proc_rdrv(adapter_t *, char *, int, int);
-#endif
static int mega_adapinq(adapter_t *, dma_addr_t);
static int mega_internal_dev_inquiry(adapter_t *, u8, u8, dma_addr_t);
+#endif
static int mega_support_ext_cdb(adapter_t *);
static mega_passthru* mega_prepare_passthru(adapter_t *, scb_t *,
_
-
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-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
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]; linux-scsi@vger.kernel.org;
[EMAIL PROTECTED]; 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] megaraid: update version reported by MEGAIOC_QDRVRVER
ACK. Thank you David. Regards, Sumant -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Milburn Sent: Thursday, April 19, 2007 10:10 AM To: [EMAIL PROTECTED] Cc: linux-scsi@vger.kernel.org; [EMAIL PROTECTED] Subject: [PATCH] megaraid: update version reported by MEGAIOC_QDRVRVER Update the driver version reported by MEGAIOC_QDRVRVER to match LSI_COMMON_MOD_VERSION. Signed-off-by: David Milburn [EMAIL PROTECTED] --- drivers/scsi/megaraid/megaraid_mm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_mm.c b/drivers/scsi/megaraid/megaraid_mm.c index f33a678..e075a52 100644 --- a/drivers/scsi/megaraid/megaraid_mm.c +++ b/drivers/scsi/megaraid/megaraid_mm.c @@ -60,7 +60,7 @@ EXPORT_SYMBOL(mraid_mm_unregister_adp); EXPORT_SYMBOL(mraid_mm_adapter_app_handle); static int majorno; -static uint32_t drvr_ver = 0x02200206; +static uint32_t drvr_ver = 0x02200207; static int adapters_count_g; static struct list_head adapters_list_g; - 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-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
FW: [PATCH] scsi: megaraid_sas - intercepts cmd timeout and throttle io
Hello James,
Is there a time frame when I may see this patch in the
scsi-misc tree ?
Regards,
Sumant
-Original Message-
From: Sumant Patro [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 28, 2007 10:44 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; Kolli, Neela; Yang, Bo; Patro, Sumant
Subject: [PATCH] scsi: megaraid_sas - intercepts cmd timeout and
throttle io
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) {
+ if (time_after(jiffies, scmd-jiffies_at_alloc + 170 *
HZ))
+ return EH_NOT_HANDLED;
+
+ 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;
+ 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;
- }
switch (hdr-cmd) {
@@ -1806,6 +1841,7 @@ static void megasas_complete_cmd_dpc(uns
u32 context;
struct megasas_cmd *cmd;
struct megasas_instance *instance = (struct megasas_instance
*)instance_addr;
+ unsigned long flags;
/* If we have already declared adapter dead, donot complete cmds
*/
if (instance-hw_crit_error)
@@ -1828,6 +1864,22 @@ static void megasas_complete_cmd_dpc(uns
}
*instance-consumer = producer;
+
+ /*
+* Check if we can restore can_queue
+*/
+ if (instance-flag MEGASAS_FW_BUSY
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-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
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-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Fw: [Bugme-new] [Bug 7999] New: MegaRAID Legacy doesn't work with LSI MegaRAID i4 since release 2.00.4
megaraid_mbox and megaraid_mm are the modules for new generation. There is no dependency of these modules to megaraid legacy. Could you please send me the lspci output from the system under test? --Sumant -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Belhomme Sent: Wednesday, February 14, 2007 1:55 AM To: James Bottomley Cc: Andrew Morton; linux-scsi@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: Fw: [Bugme-new] [Bug 7999] New: MegaRAID Legacy doesn't work with LSI MegaRAID i4 since release 2.00.4 James Bottomley a écrit : So if I understand well, the module actively used with the LSI card is megaraid, the legacy one ! but the mbox and mm are loaded and seems to be necessary for the legacy driver ? Actually, it shouldn't be. megaraid_mbox depends on megaraid_mm as your lsmod shows, which is correct. However, nothing's depending on legacy megaraid ... I'm not sure why it's showing as loaded and in use. but it is ! moreover I have a /proc/megaraid/hba1/ directory structure fully filled with my RAID card, drives, and RAID volumes informations, and I don't hav any entry in sysfs directory tree (witch is the right place for megaraid NG module) I'd like to understand _why_ this module supposed to be independant from the new generation megaraid module needs megaraid NG to be compiled to work correctly ? I looked over the sources but I didn't found any link between the legacy driver and the newgen one... quite strange ! Regards, -- Rico - 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-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/5] 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-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
megaraid_sas : Error message from SYNC CACHE cmd fills up kernel log
MegaRAID (MR) SAS Adapter FW is exposing VDs (Logical Disks) with WCE enabled in Mode Sense command for drives that are configured as WriteBack by the user. When the VDs are exported as Write Back drives, OS is sending Synchronize Cache command to the drives frequently. Per SCSI Spec, this command is an optional command and MR firmware is rejecting this command as unsupported. User is advised to enable Write back only when battery is available (in Adapter) The FW does flush cache periodically. Looks like OS do not like rejecting the command on a boot volume and so adding the following event message to the event log each time the call is failed. These messages are flooded by OS and is causing annoyance to the user. Message from the log : Jan 12 17:58:06 linux kernel: FAILED Jan 12 17:58:07 linux kernel: status = 1, message = 00, host = 0, driver = 08 Jan 12 17:58:07 linux kernel: 6sd: Current: sense key: Illegal Request Jan 12 17:58:07 linux kernel: Additional sense: Invalid command operation code 1. Shouldn't the OS stop sending the sync cache cmd if it sees it is Failed with Invalid Command in sense info ? 2. Is there a way by which LLD can stop the OS from sending the SYNC cmd down? Thanks, Sumant - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: 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-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] megaraid: fix kernel-doc
Thanks Randy for the patch.
Regards,
Sumant
-Original Message-
From: Randy Dunlap [mailto:[EMAIL PROTECTED]
Sent: Friday, January 05, 2007 10:42 PM
To: Patro, Sumant; scsi
Cc: jejb; akpm
Subject: [PATCH] megaraid: fix kernel-doc
From: Randy Dunlap [EMAIL PROTECTED]
kernel-doc modifications:
- change @param var notation to @var;
- change function/description separator from ':' to '-';
- change var/description separator from '-' to ':';
- fix a few doc. typos;
- don't use kernel-doc /** lead-in when the doc. block is not
kernel-doc;
- use Linux common */ ending comment format instead of **/;
- use correct function parameter names;
- place function parameters immediately after the function short
description;
- place kernel-doc immediately before its function or macro;
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
drivers/scsi/megaraid/mega_common.h| 120 ++---
drivers/scsi/megaraid/megaraid_ioctl.h | 36 ++--
drivers/scsi/megaraid/megaraid_mbox.c | 285
-
drivers/scsi/megaraid/megaraid_mbox.h | 42 ++--
drivers/scsi/megaraid/megaraid_mm.c| 65 +++
drivers/scsi/megaraid/megaraid_sas.h | 14 -
6 files changed, 275 insertions(+), 287 deletions(-)
--- linux-2620-rc3g4.orig/drivers/scsi/megaraid/mega_common.h
+++ linux-2620-rc3g4/drivers/scsi/megaraid/mega_common.h
@@ -46,17 +46,17 @@
/**
* scb_t - scsi command control block
- * @param ccb : command control block for individual driver
- * @param list : list of control blocks
- * @param gp : general purpose field for LLDs
- * @param sno : all SCBs have a serial number
- * @param scp : associated scsi command
- * @param state: current state of scb
- * @param dma_dir : direction of data transfer
- * @param dma_type : transfer with sg list, buffer, or no data
transfer
- * @param dev_channel : actual channel on the device
- * @param dev_target : actual target on the device
- * @param status : completion status
+ * @ccb: command control block for individual
driver
+ * @list : list of control blocks
+ * @gp : general purpose field for LLDs
+ * @sno: all SCBs have a serial number
+ * @scp: associated scsi command
+ * @state : current state of scb
+ * @dma_dir: direction of data transfer
+ * @dma_type : transfer with sg list, buffer, or no data
transfer
+ * @dev_channel: actual channel on the device
+ * @dev_target : actual target on the device
+ * @status : completion status
*
* This is our central data structure to issue commands the each
driver.
* Driver specific data structures are maintained in the ccb field.
@@ -99,42 +99,42 @@ typedef struct {
/**
* struct adapter_t - driver's initialization structure
- * @param dpc_h: tasklet handle
- * @param pdev : pci configuration pointer for kernel
- * @param host : pointer to host structure of mid-layer
- * @param lock : synchronization lock for mid-layer and
driver
- * @param quiescent: driver is quiescent for now.
- * @param outstanding_cmds : number of commands pending in the
driver
- * @param kscb_list: pointer to the bulk of SCBs pointers
for IO
- * @param kscb_pool: pool of free scbs for IO
- * @param kscb_pool_lock : lock for pool of free scbs
- * @param pend_list: pending commands list
- * @param pend_list_lock : exlusion lock for pending commands
list
- * @param completed_list : list of completed commands
- * @param completed_list_lock : exclusion lock for list of completed
commands
- * @param sglen: max sg elements supported
- * @param device_ids : to convert kernel device addr to our
devices.
- * @param raid_device : raid adapter specific pointer
- * @param max_channel : maximum channel number supported -
inclusive
- * @param max_target : max target supported - inclusive
- * @param max_lun : max lun supported - inclusive
- * @param unique_id: unique identifier for each adapter
- * @param irq : IRQ for this adapter
- * @param ito : internal timeout value, (-1) means no
timeout
- * @param ibuf : buffer to issue internal commands
- * @param ibuf_dma_h : dma handle for the above buffer
- * @param uscb_list: SCB pointers for user cmds, common
mgmt module
- * @param uscb_pool: pool of SCBs for user commands
- * @param uscb_pool_lock : exclusion lock for these SCBs
- * @param max_cmds : max outstanding commands
- * @param fw_version : firmware version
- * @param bios_version : bios version
- * @param max_cdb_sz
RE: [PATCH] megaraid: more kernel-doc fixes
ACK.
--Sumant
-Original Message-
From: Randy Dunlap [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 09, 2007 9:41 PM
To: Patro, Sumant
Cc: jejb; akpm; scsi
Subject: [PATCH] megaraid: more kernel-doc fixes
From: Randy Dunlap [EMAIL PROTECTED]
More megaraid kernel-doc fixes.
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
drivers/scsi/megaraid/mbox_defs.h |2 +-
drivers/scsi/megaraid/mega_common.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.20-rc3-mm1.orig/drivers/scsi/megaraid/mbox_defs.h
+++ linux-2.6.20-rc3-mm1/drivers/scsi/megaraid/mbox_defs.h
@@ -748,7 +748,7 @@ typedef struct {
/**
- * private_bios_data - bios private data for boot devices
+ * struct private_bios_data - bios private data for boot devices
* @geometry : bits 0-3 - BIOS geometry, 0x0001 - 1GB, 0x0010 - 2GB,
* 0x1000 - 8GB, Others values are invalid
* @unused : bits 4-7 are unused
--- linux-2.6.20-rc3-mm1.orig/drivers/scsi/megaraid/mega_common.h
+++ linux-2.6.20-rc3-mm1/drivers/scsi/megaraid/mega_common.h
@@ -271,7 +271,7 @@ typedef struct {
#define ASSERT(expression)
#endif
-/*
+/**
* struct mraid_pci_blk - structure holds DMA memory block info
* @vaddr : virtual address to a memory block
* @dma_addr : DMA handle to a memory block
---
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] 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-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: megaraid_sas xscale interrupt mask?
Hello Joe,
The mask value 0x1f is to mask out interrupts. The value in the
current kernel code is appropriate for all controllers that the driver
supports.
Are you seeing any specific issue in driver with this mask
value?
Regards,
Sumant
-Original Message-
From: Joe Malicki [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 03, 2007 5:41 PM
To: Patro, Sumant
Cc: [EMAIL PROTECTED]; Keith R. Baker; linux-scsi@vger.kernel.org
Subject: megaraid_sas xscale interrupt mask?
Hi Sumant,
While trying to debug Dell PERC 5/i RAID controller problems we've been
having with the megaraid_sas driver, we've been inspecting differences
between the Red Hat EL 4 kernel (which Dell officially supports) versus
the stock Linux 2.6.17.13 driver we use. We found a very interesting
change, introduced into linux 2.6.16, that seems very odd to us:
http://groups.google.com/group/fa.linux.kernel/browse_frm/thread/51f889b
d09bafd2d/cbbe2a30b8c2eb94?lnk=stq=outbound_intr_mask+0x1f+0x0001r
num=1#cbbe2a30b8c2eb94
The title of the thread is megaraid_sas: new template defined to
represent each type of controllers, and introduces this curious change:
/**
* megasas_disable_intr - Disables interrupts
* @regs: MFI register set
*/
static inline void
megasas_disable_intr(struct megasas_register_set __iomem * regs) {
- u32 mask = readl(regs-outbound_intr_mask) (~0x0001);
+ u32 mask = 0x1f;
writel(mask, regs-outbound_intr_mask);
/* Dummy readl to force pci flush */
Interrupts are enabled by writing 1 to the same register.
Is there a specific reason for this? Is it possible that Dell PERC 5/i
controllers differ from LSI controllers in this respect? It seems odd
that this change would be introduced without any explanation for what
it's meant to do, so I am very curious if it could be an inadvertently
introduced bug that is causing some problems.
Thanks!
Joe Malicki
--
Joseph Malicki
Software Engineer
Metacarta, Inc.
350 Massachusetts Avenue
4th Floor
Cambridge, MA 02451 USA
email: [EMAIL PROTECTED]
http://www.metacarta.com
Joe Malicki wrote:
After upgrading to the new 5.0.3-0001 package build firmware,
released 12/12/06, from
http://support.dell.com/support/downloads/format.aspx?c=usl=ens=gen;
osl=endeviceid=9182releaseid=R141188,
we just experienced one firmware problem that's leaving a clear
traceback. I don't know if this is
1) the same problem we were experiencing before, that the new firmware
introduced debugging/a detailed error message for (if this is the
case, I do really appreciate that Dell did this, since it may help to
fix these problems eventually),
2) A problem introduced by the new firmware, or
3) A preexisting problem that we never happened to experience before.
In the firmware logs at the end of this message, note that just 15
minutes after a battery relearn is finished and the battery finished
charging, we see the message:
01/02/07 0:33:50: Diag Retention test is running...all activities are
stopped
This corresponds to when the megasas driver timed out SCSI commands
and the controller stopped responding.
1) Does anyone know what a Diag Retention test is? Documentation
mentions BBU Retention tests and NVRAM Retention tests, but not
Diag Retention test - is the Diag Retention test a synonym for one
of these, or is it something different?
2) Has anyone seen a similar failure?
Note that 4 hours after the controller has been offline, a stack
backtrace, with a firmware source code file and line number, appears
in the firmware logs - which is something I wouldn't expect to happen
under any circumstances on a stable product - and seems to drop to a
debug console (we haven't tried hooking up a serial port to what look
like the headers on the PERC card, we didn't experiment too much the
first time it happened as it's a production machine we wanted to get
back up quickly).
We have previously noticed failures corresponding with patrol reads,
and this failure takes place several hours later, and the traceback
happens within the PatrolReadTimer procedure - is this the same
failure as before?
We don't yet have a clear reproduction case, but are working on it
with additional information we have from this crash (as we've begun
remote logging to capture the state of the machine as it's dying,
since syslog failing because it couldn't write to disk in previous
crashes lowered the amount of information we could get).
Thanks,
Joe
Logs follow:
01/01/07 20:16:57: PR cycle complete
01/01/07 20:16:57: EVT#06277-01/01/07 20:16:57: 35=Patrol Read
complete
01/01/07 20:16:57: Next PR scheduled to start at 01/02/07 18:13:20
01/01/07 21:17:01: EVT#06278-01/01/07 21:17:01: 44=Time established
as
01/01/07 21:17:01; (1727059 seconds since power on)
01/01/07 21:23:40: EVT#06279-01/01/07 21:23:40: 162=Current capacity
of the battery
