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 #include #include +#include #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=10659&start > =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 >
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] Use legacy driver for NetRAID 1M/2M controllers
NACK. ID being added is already supported in megaraid_mbox driver. Please use megaraid_mbox driver. --Sumant -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of dann frazier Sent: Tuesday, September 18, 2007 6:05 PM To: DL-MegaRAID Linux Cc: linux-scsi@vger.kernel.org Subject: [PATCH] Use legacy driver for NetRAID 1M/2M controllers Debian has had a long-standing bug concerning certain NetRAID controllers that were moved over to the megaraid driver: http://bugs.debian.org/317258 The reporters claim that the legacy driver works just fine for them. I've been unable to reproduce this with the 2M cards I have access to, which use the following firmware revs: BIOS Firmware - G.02.03 H.02.00 J.01.01 K.01.03 As these cards work fine with both the new and legacy drivers, and there are cards known to only work with the legacy driver, please consider the following patch which moves the support of these cards back to the legacy driver. Signed-off-by: dann frazier <[EMAIL PROTECTED]> diff --git a/drivers/scsi/megaraid.c b/drivers/scsi/megaraid.c index 3907f67..ac96dbb 100644 --- a/drivers/scsi/megaraid.c +++ b/drivers/scsi/megaraid.c @@ -24,6 +24,7 @@ * * Supported controllers: MegaRAID 418, 428, 438, 466, 762, 467, 471, 490, 493 * 518, 520, 531, 532 + * NetRAID 1M, 2M * * This driver is supported by LSI Logic, with assistance from Red Hat, Dell, * and others. Please send updates to the mailing list @@ -4967,6 +4968,10 @@ static struct pci_device_id megaraid_pci_tbl[] = { PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, {PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_AMI_MEGARAID2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, + {PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_AMI_MEGARAID3, + HP_SUBSYS_VID, PCI_SUBSYS_ID_HP_NETRAID_1M, 0, 0, 0}, + {PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_AMI_MEGARAID3, + HP_SUBSYS_VID, PCI_SUBSYS_ID_HP_NETRAID_2M, 0, 0, 0}, {PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_AMI_MEGARAID3, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, {0,} diff --git a/drivers/scsi/megaraid.h b/drivers/scsi/megaraid.h index ee70bd4..697276a 100644 --- a/drivers/scsi/megaraid.h +++ b/drivers/scsi/megaraid.h @@ -84,6 +84,10 @@ #define LSI_SUBSYS_VID 0x1000 #define INTEL_SUBSYS_VID 0x8086 +/* Sub-System Device IDs */ +#define PCI_SUBSYS_ID_HP_NETRAID_1M0x60E7 +#define PCI_SUBSYS_ID_HP_NETRAID_2M0x60E8 + #define HBA_SIGNATURE 0x3344 #define HBA_SIGNATURE_471 0x #define HBA_SIGNATURE_64BIT0x0299 diff --git a/drivers/scsi/megaraid/megaraid_mbox.c b/drivers/scsi/megaraid/megaraid_mbox.c index 4963b96..0d74241 100644 --- a/drivers/scsi/megaraid/megaraid_mbox.c +++ b/drivers/scsi/megaraid/megaraid_mbox.c @@ -443,6 +443,14 @@ megaraid_probe_one(struct pci_dev *pdev, const struct pci_device_id *id) con_log(CL_ANN, ("bus %d:slot %d:func %d\n", pdev->bus->number, PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn))); + /* Some NetRAID 1M and 2M controllers still need the legacy driver */ + if (pdev->vendor == PCI_VENDOR_ID_AMI && \ + pdev->device == PCI_DEVICE_ID_AMI_MEGARAID3 && \ + pdev->subsystem_vendor == PCI_VENDOR_ID_HP && \ + (pdev->subsystem_device == PCI_SUBSYS_ID_HP_NETRAID_1M || \ +pdev->subsystem_device == PCI_SUBSYS_ID_HP_NETRAID_2M)) + return -ENODEV; + if (pci_enable_device(pdev)) { con_log(CL_ANN, (KERN_WARNING "megaraid: pci_enable_device failed\n")); diff --git a/drivers/scsi/megaraid/megaraid_mbox.h b/drivers/scsi/megaraid/megaraid_mbox.h index 2e760c2..c66d107 100644 --- a/drivers/scsi/megaraid/megaraid_mbox.h +++ b/drivers/scsi/megaraid/megaraid_mbox.h @@ -89,6 +89,8 @@ #define PCI_SUBSYS_ID_PERC3_DC 0x0493 #define PCI_SUBSYS_ID_PERC3_SC 0x0475 +#define PCI_SUBSYS_ID_HP_NETRAID_1M0x60E7 +#define PCI_SUBSYS_ID_HP_NETRAID_2M0x60E8 #define MBOX_MAX_SCSI_CMDS 128 // number of cmds reserved for kernel #define MBOX_MAX_USER_CMDS 32 // number of cmds for applications - 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 10/30] megaraid: add CERC_ATA100 support
NACK. ID being added is already supported in megaraid_mbox driver. --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]; [EMAIL PROTECTED] Subject: [patch 10/30] megaraid: add CERC_ATA100 support From: Torsten Krah <[EMAIL PROTECTED]> Taken from http://bugzilla.kernel.org/show_bug.cgi?id=6695 Add support for this device to the old megaraid driver. Cc: Natalie Protasevich <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- drivers/scsi/megaraid.c |2 ++ drivers/scsi/megaraid.h |2 ++ 2 files changed, 4 insertions(+) diff -puN drivers/scsi/megaraid.c~megaraid-add-cerc_ata100-support drivers/scsi/megaraid.c --- a/drivers/scsi/megaraid.c~megaraid-add-cerc_ata100-support +++ a/drivers/scsi/megaraid.c @@ -4967,6 +4967,8 @@ static struct pci_device_id megaraid_pci PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, {PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_AMI_MEGARAID2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, + {PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_AMI_MEGARAID3, + PCI_VENDOR_ID_DELL, PCI_SUBSYS_ID_CERC_ATA100, 0, 0, 0}, {PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_AMI_MEGARAID3, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, {0,} diff -puN drivers/scsi/megaraid.h~megaraid-add-cerc_ata100-support drivers/scsi/megaraid.h --- a/drivers/scsi/megaraid.h~megaraid-add-cerc_ata100-support +++ a/drivers/scsi/megaraid.h @@ -84,6 +84,8 @@ #define LSI_SUBSYS_VID 0x1000 #define INTEL_SUBSYS_VID 0x8086 +#define PCI_SUBSYS_ID_CERC_ATA100 0x0511 + #define HBA_SIGNATURE 0x3344 #define HBA_SIGNATURE_471 0x #define HBA_SIGNATURE_64BIT0x0299 _ - 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 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] [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 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 #include #include +#include #include #include #include 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/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; linux-scsi@vger.kernel.org Cc: [EMAIL PROTECTED]; [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(&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-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 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 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] 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, >
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
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/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-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: 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 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
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
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: <6>sd: 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: <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-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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] 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 vers
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=st&q=outbound_intr_mask+0x1f+0x0001&r 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(®s->outbound_intr_mask) & (~0x0001); + u32 mask = 0x1f; writel(mask, ®s->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=us&l=en&s=gen&; > osl=en&deviceid=9182&releaseid=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 &g
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-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html