1. Add the CTIO support to the driver 2. Add the Online controller reset support to the driver 3. driver will auto update the devices add/delete to the system without megaraid application installed.
*** Bug 563370 has been marked as a duplicate of this bug. ***
Created attachment 398826 [details] Add the megaraid sas 4.27 driver patch to rhel5.6 This is the patch to upgrade megaraid sas driver to version 4.27
Bo - you planning on submitting 4.27 or 4.28 as an update soon?
Andrius, Do I need new IDs to submit the new driver? I have 4.31. Thanks, Bo Yang
Tomas, have you started work on the 4.26 driver previously attached? Bo, the answer to your question depends on if Tomas has already submitted 4.26 driver internally...
(In reply to comment #10) Post the additional set here, so that in result we have one patch for 4.27 and the other for 4.31. (We prefer smaller patches not on big patch). Please post the new set also in upstream, it is better you do it now so we do not end in various problems like the last time. Thanks, Tomas
Tomas, Does 4.27 already in RHEL5.6? If yes, I only need to post the diff between 4.27 and 4.31. Regards, Bo Yang
(In reply to comment #13) > Does 4.27 already in RHEL5.6? If yes, I only need to post the diff between > 4.27 and 4.31. It is not. Use the patch you posted here as a base for your new incremental patch. And yes post only the diff between 4.27 and 4.31.
*** Bug 568570 has been marked as a duplicate of this bug. ***
Created attachment 424193 [details] attached the 4.31 patch (based on 4.27 driver) 1. Add the three times online controller reset if driver detects the fw in failure state. also do online controller reset (OCR) before driver kill adapter to have the last chance to bringup FW. 2. Add input parameter of max_sectors to 1MB. Customer can change the max_sectors size upto 1MB. 3. Fix the issue of during the system reboot test, FW raises the interrupt as FW state change and system hang. 4. Fix the issue of fw report the enclure as system PDs.
(In reply to comment #17) > Created an attachment (id=424193) [details] > attached the 4.31 patch (based on 4.27 driver) There are some compile issues, please correct that, thanks, tomas # make -j16 drivers/scsi/megaraid/ CHK include/linux/version.h CHK include/linux/utsrelease.h CC [M] drivers/scsi/megaraid/megaraid_sas.o drivers/scsi/megaraid/megaraid_sas.c: In function ‘sysfs_max_sectors_read’: drivers/scsi/megaraid/megaraid_sas.c:3766: warning: initialization from incompatible pointer type drivers/scsi/megaraid/megaraid_sas.c: At top level: drivers/scsi/megaraid/megaraid_sas.c:3783: warning: initialization from incompatible pointer type drivers/scsi/megaraid/megaraid_sas.c: In function ‘megasas_io_attach’: drivers/scsi/megaraid/megaraid_sas.c:3850: error: ‘struct Scsi_Host’ has no member named ‘shost_dev’ make[1]: *** [drivers/scsi/megaraid/megaraid_sas.o] Error 1 make: *** [drivers/scsi/megaraid/] Error 2
Bo, do you need some help with this?
Created attachment 426198 [details] patch proposed by Fujitsu Comment from Fujitsu: I think something like this patch should work. - Fixes the compile error - Changes to use class_device_attribute instead of bin_attribute, so sysfs entry "max_sectors" will appear in /sys/class/scsi_host/host#/ (But, I'm not sure if it's the place LSI wants to have it.) - Adds class_device_remove_file() in megasas_detach_one() Bo, Tomas, Could you take a look at it, please? Kei Tokunaga
I will get back to you today.
Tomas, Please apply the following patch to fix this issue (I am also attach the patch): diff -rupN old/drivers/scsi/megaraid/megaraid_sas.c new/drivers/scsi/megaraid/megaraid_sas.c --- old/drivers/scsi/megaraid/megaraid_sas.c 2010-06-22 13:25:52.000000000 -0400 +++ new/drivers/scsi/megaraid/megaraid_sas.c 2010-06-22 13:53:11.000000000 -0400 @@ -3758,17 +3758,17 @@ static int megasas_start_aen(struct mega } static ssize_t -sysfs_max_sectors_read(struct kobject *kobj, struct bin_attribute *bin_attr, - char *buf, loff_t off, size_t count) +sysfs_max_sectors_read(struct kobject *kobj, char *buf, + loff_t off, size_t count) { - struct device *dev = container_of(kobj, struct device, kobj); - - struct Scsi_Host *host = class_to_shost(dev); - + + struct Scsi_Host *host = class_to_shost(container_of(kobj, + struct class_device, kobj)); + struct megasas_instance *instance = (struct megasas_instance *)host->hostdata; - count = sprintf(buf, "%u\n", instance->max_sectors_per_req); + count = sprintf(buf,"%u\n", instance->max_sectors_per_req); return count+1; } @@ -3847,8 +3847,9 @@ static int megasas_io_attach(struct mega /* * Create sysfs entries for module paramaters */ - error = sysfs_create_bin_file(&instance->host->shost_dev.kobj, - &sysfs_max_sectors_attr); + error = sysfs_create_bin_file(&instance->host->shost_classdev.kobj, + &sysfs_max_sectors_attr); + if (error) { printk(KERN_INFO "megasas: Error in creating the sysfs entry"
Event posted on 06-25-2010 05:01pm JST by moshiro Hi, Forwarding Fujitsu's comment: ============================================================ > Tomas, > > Please apply the following patch to fix this issue (I am also attach the > patch): > > diff -rupN old/drivers/scsi/megaraid/megaraid_sas.c > new/drivers/scsi/megaraid/megaraid_sas.c > --- old/drivers/scsi/megaraid/megaraid_sas.c 2010-06-22 13:25:52.000000000 > -0400 > +++ new/drivers/scsi/megaraid/megaraid_sas.c 2010-06-22 13:53:11.000000000 > -0400 > @@ -3758,17 +3758,17 @@ static int megasas_start_aen(struct mega > } > > static ssize_t > -sysfs_max_sectors_read(struct kobject *kobj, struct bin_attribute *bin_attr, > - char *buf, loff_t off, size_t count) > +sysfs_max_sectors_read(struct kobject *kobj, char *buf, > + loff_t off, size_t count) > { > - struct device *dev = container_of(kobj, struct device, kobj); > - > - struct Scsi_Host *host = class_to_shost(dev); > - > + > + struct Scsi_Host *host = class_to_shost(container_of(kobj, > + struct class_device, kobj)); > + > struct megasas_instance *instance = > (struct megasas_instance *)host->hostdata; > > - count = sprintf(buf, "%u\n", instance->max_sectors_per_req); > + count = sprintf(buf,"%u\n", instance->max_sectors_per_req); > > return count+1; > } > @@ -3847,8 +3847,9 @@ static int megasas_io_attach(struct mega > /* > * Create sysfs entries for module paramaters > */ > - error = sysfs_create_bin_file(&instance->host->shost_dev.kobj, > - &sysfs_max_sectors_attr); > + error = sysfs_create_bin_file(&instance->host->shost_classdev.kobj, > + &sysfs_max_sectors_attr); > + > > if (error) { > printk(KERN_INFO "megasas: Error in creating the sysfs entry" With this patch, it compiles just fine. One minor thing is that "max_sectors" sysfs file shows its value twice. # cat /sys/class/scsi_host/host0/max_sectors 640 640 Kei Tokunaga ============================================================ This event sent from IssueTracker by moshiro issue 962043
(In reply to comment #23) > > One minor thing is that "max_sectors" sysfs file shows its value twice. > > # cat /sys/class/scsi_host/host0/max_sectors > 640 > 640 This is new with this patch? I've such a feeling I've already talked with Bo about this in the past.
(In reply to comment #22) Bo, I'm just working on the test kernel. Let us expect it will work properly for now. Could you please in the meantime refresh the bz#602714 and post a patch there also? Thanks, Tomas
Hi Tomas, (In reply to comment #24) > (In reply to comment #23) > > > > One minor thing is that "max_sectors" sysfs file shows its value twice. > > > > # cat /sys/class/scsi_host/host0/max_sectors > > 640 > > 640 > > This is new with this patch? > I've such a feeling I've already talked with Bo about this in the past. From FJ: ============================================================= >> One minor thing is that "max_sectors" sysfs file shows its value twice. >> >> # cat /sys/class/scsi_host/host0/max_sectors >> 640 >> 640 > > This is new with this patch? It's not new with the patch posted on Comment 22, but with the one posted on Comment 17 as the max_sectors file was introduced by it. > I've such a feeling I've already talked with Bo about this in the past. Ah, OK. Thanks for the information.
Created attachment 432149 [details] diff file generated from comment-22 diff file generated from comment-22 in this bz enabling update to 4.31 to compile
Request Fujitsu commit to testing this update in rhel5.6
Bo, While reviewing the updates here against what you proposed for the rhel5.3z update, I noticed a few snippets from the diffs that looked like they might apply to the other versions of the driver. Can you review the 5.3 version after the patch in bz602714 against the updates here and determine if any updates should be applied in the other? Thanks, Rob What I noticed: Patch for 5.3 contains: /** + * megasas_check_reset_gen2 - For controller reset check + * @regs: MFI register set + */ +static int +megasas_check_reset_gen2(struct megasas_instance *instance, struct megasas_register_set __iomem * regs) +{ + if (instance->adprecovery != MEGASAS_HBA_OPERATIONAL) { + return 1; + } + + return 0; +} Corresponding rhel5.6 patch snippet: +/** + * megasas_check_reset_gen2 - For controller reset check + * @regs: MFI register set + */ +static int +megasas_check_reset_gen2(struct megasas_instance *instance, struct megasas_register_set __iomem * regs) +{ + return 0; +} + Why the differences? Patch for 5.3 contains: /* If we have already declared adapter dead, donot complete cmds */ - if (instance->hw_crit_error) + if (instance->adprecovery == MEGASAS_HW_CRITICAL_ERROR ) return; Rhel5.6 version of patch has: /* If we have already declared adapter dead, donot complete cmds */ - if (instance->hw_crit_error) + spin_lock_irqsave(&instance->hba_lock, flags); + if (instance->adprecovery == MEGASAS_HW_CRITICAL_ERROR ) { + spin_unlock_irqrestore(&instance->hba_lock, flags); return; + } + spin_unlock_irqrestore(&instance->hba_lock, flags); Is the locking needed in 5.3z patch as well?
(In reply to comment #28) > Request Fujitsu commit to testing this update in rhel5.6 Could you provide a test kernel now, please? I'd like to do the retest ASAP. Note that we have requested the same fix also for RHEL6.0 (bug #607930).
Bo, Can you please remove // style comments in your next rhel5.6 update for the megaraid driver? Thanks, Rob
(In reply to comment #30) > (In reply to comment #28) > > Request Fujitsu commit to testing this update in rhel5.6 > > Could you provide a test kernel now, please? I'd like to do the retest ASAP. > Note that we have requested the same fix also for RHEL6.0 (bug #607930). Hopefully early next week. I'm on pto tomorrow and am still trying to get these patches posted.
(In reply to comment #34) Yes, please make and test the rhel5.6 patch against the current rhel5.6 sources.
Created attachment 433362 [details] recreate the patch for rhel5.6 (from 4.17 to 4.31) Rob, This patch based on the src from: http://people.redhat.com/jwilson/el5/206.el5/ Also take off the // in the src.
(In reply to comment #36) > Created an attachment (id=433362) [details] > recreate the patch for rhel5.6 (from 4.17 to 4.31) > > Rob, > > This patch based on the src from: > http://people.redhat.com/jwilson/el5/206.el5/ > > Also take off the // in the src. Thanks Bo. In the interest of getting this posted, and enabling the 5.3z patch in bz602714, I am obsoleting this patch. Can get these changes in using a new bz for rhel5.6. This is not a pressing issue at the moment. Please use the rhel5.6 base with the three patches that are not obsoleted here at the code base for the new bz. Thanks, Rob
Hi Bo, It was brought to my attention that there is an outstanding rhel5 kdump issue as well: https://bugzilla.redhat.com/show_bug.cgi?id=435698 Do you typically test kdump before providing driver updates? This is pretty important for Red Hat. I recommend testing kdump under load and repeatedly, perhaps 10 times? Rob
(In reply to comment #38) > (In reply to comment #36) > > Created an attachment (id=433362) [details] [details] > > recreate the patch for rhel5.6 (from 4.17 to 4.31) > > > > Rob, > > > > This patch based on the src from: > > http://people.redhat.com/jwilson/el5/206.el5/ > > > > Also take off the // in the src. > > Thanks Bo. In the interest of getting this posted, and enabling the 5.3z patch > in bz602714, I am obsoleting this patch. Can get these changes in using a new > bz for rhel5.6. This is not a pressing issue at the moment. > > Please use the rhel5.6 base with the three patches that are not obsoleted here > at the code base for the new bz. > > Thanks, Rob Bo, When I posted this patch internally, another issue came up. The maintainer of the rhel5.6 kernel prefers that all the issues get addressed before this will get accepted in rhel5.6. This means the rhel5.3-z update is still blocked until this gets accepted. Can you: - Post an update for the issue below on linux-scsi - add another patch to this bz that addresses the issue for rhel5.6. Please make this patch apply on top of the last patch you attached here. I will remove the obsolete status of it. Once this is done, all 4 patches can then be re-posted internally and all should be good. Not sure if you opened another rhel5.6 bz for megaraid-sas yet but it won't be needed after this. See issue below. Thanks, Rob The new issue that came up: > > +static ssize_t > +sysfs_max_sectors_read(struct kobject *kobj, char *buf, > + loff_t off, size_t count) > +{ > + struct Scsi_Host *host = > + class_to_shost(container_of(kobj, > + struct class_device, kobj)); > + > + struct megasas_instance *instance = > + (struct megasas_instance *)host->hostdata; > + > + count = sprintf(buf, "%u\n", instance->max_sectors_per_req); > + > + return count+1; > +} > + > +static struct bin_attribute sysfs_max_sectors_attr = { > + .attr = { > + .name = "max_sectors", > + .mode = S_IRUSR|S_IRGRP|S_IROTH, > + .owner = THIS_MODULE, > + }, > + .size = 7, > + .read = sysfs_max_sectors_read, > +}; I do not think this needs to be a binary sysfs file. It should be a scsi_host_template->shost_attrs attr. Maybe it could even be a default scsi_sysfs.c:scsi_sysfs_shost_attrs attr.
Rob, I am trying to understand the issue. If you can give me the details of the issue, I can test the changes and see the fix. I am in China Now and am traving back to US. Hope I can do the test on next Monday or Tuesday after I back to office. Bo Yang
(In reply to comment #41) > I am trying to understand the issue. If you can give me the details of the > issue, I can test the changes and see the fix. The issues are a) that the max_sectors shouldn't be a binary sysfs file, but added under scsi_host_template->shost_attrs attr. b) kdump. I haven't tested kdump with your latest patch (I'll do that). Have you done some kdump testing?
(In reply to comment #42) > a) that the max_sectors shouldn't be a binary sysfs file, but added under > scsi_host_template->shost_attrs attr. For an example look here: drivers/scsi/megaraid/megaraid_mbox.c static struct scsi_host_template megaraid_template_g = { ... .shost_attrs = megaraid_shost_attrs,
Tomas, As I comment #41, I am doing the changes and test it. Regards, Bo Yang
Created attachment 435115 [details] change the max_sectors sysfs from bin attr to scsi host attr Tomas, Please find the attached patch for this changes. I tested it works fine.
*** Bug 602714 has been marked as a duplicate of this bug. ***
as bug 602714 is closed as a duplicate of this one, moving z-stream proposals here.
Poasted today http://post-office.corp.redhat.com/archives/rhkernel-list/2010-July/msg01550.html
(In reply to comment #45) > Created an attachment (id=435115) [details] > change the max_sectors sysfs from bin attr to scsi host attr > > Tomas, > > Please find the attached patch for this changes. I tested it works fine. Thanks Bo
Hi Bo, please could you answer (if possible today) these question, originally in comment#29, but they are still valid. Thanks, Tomas Patch for 5.3 contains: /** + * megasas_check_reset_gen2 - For controller reset check + * @regs: MFI register set + */ +static int +megasas_check_reset_gen2(struct megasas_instance *instance, struct megasas_register_set __iomem * regs) +{ + if (instance->adprecovery != MEGASAS_HBA_OPERATIONAL) { + return 1; + } + + return 0; +} Corresponding rhel5.6 patch snippet: +/** + * megasas_check_reset_gen2 - For controller reset check + * @regs: MFI register set + */ +static int +megasas_check_reset_gen2(struct megasas_instance *instance, struct megasas_register_set __iomem * regs) +{ + return 0; +} + Why the differences? Patch for 5.3 contains: /* If we have already declared adapter dead, donot complete cmds */ - if (instance->hw_crit_error) + if (instance->adprecovery == MEGASAS_HW_CRITICAL_ERROR ) return; Rhel5.6 version of patch has: /* If we have already declared adapter dead, donot complete cmds */ - if (instance->hw_crit_error) + spin_lock_irqsave(&instance->hba_lock, flags); + if (instance->adprecovery == MEGASAS_HW_CRITICAL_ERROR ) { + spin_unlock_irqrestore(&instance->hba_lock, flags); return; + } + spin_unlock_irqrestore(&instance->hba_lock, flags); Is the locking needed in 5.3z patch as well?
Tomas, Patch for 5.3 contains: /** + * megasas_check_reset_gen2 - For controller reset check + * @regs: MFI register set + */ +static int +megasas_check_reset_gen2(struct megasas_instance *instance, struct megasas_register_set __iomem * regs) +{ + if (instance->adprecovery != MEGASAS_HBA_OPERATIONAL) { + return 1; + } + + return 0; +} Corresponding rhel5.6 patch snippet: +/** + * megasas_check_reset_gen2 - For controller reset check + * @regs: MFI register set + */ +static int +megasas_check_reset_gen2(struct megasas_instance *instance, struct megasas_register_set __iomem * regs) +{ + return 0; +} + Why the differences? The changes was made after we submited the rhel5.6 patch (version 4.32) which is required for rhel5.6. The lock in 5.6 is required for 5.3z. Regards, Bo Yang
Tomas, You can send me the e-mail if you want to know the information immidiately or make changes. Regards, Bo Yang
Event posted on 2010-07-30 14:50 JST by myamazak Hi all, I'll forward a comment from FJ. ---------------------------------------------------------------------- --- Hereafter, we will test test kernel (5.3 x86_64). --- We tested the test kernel (5.3 x86_64) and confirmed there is no problem with it. Moreover, could you please make the PAE test kernel available for us? --- New bugzilla tickets for z-stream have been created. --- Thank you for the information. Best Regards, Masahiro Maeda ---------------------------------------------------------------------- Regards, M Yamazaki This event sent from IssueTracker by myamazak issue 1000913
(In reply to comment #58) > We tested the test kernel (5.3 x86_64) and confirmed there is no problem > with it. > Moreover, could you please make the PAE test kernel available for us? > Uploaded to http://people.redhat.com/thenzl/602714/ Sorry my diskspace there is limited so I can't post all the kernels, let me know if you need some other arch.
(In reply to comment #56) > > The lock in 5.6 is required for 5.3z. > Bo, to sum it up the first change is OK, because something else has also changed - OK? The second issue - the lock. I just checked the sources and the "instance->adrecovery" is often protected with a lock but also often it is not protected. It's really hard for me to be sure where the lock is not needed. Please repost the 5.3.z patch with corrected locking. If a change is needed to the 5.6 patch please repost it also. Thanks, Tomas
Created attachment 435585 [details] changed the max_sectors again Bo, the latest version of the max_sectors sys has been rejected on our internal list. This one has passed. Please let me know if you are OK with this version, if possible retest in your lab. When you would want to change something else in your patch (locking) use the patch here so the changes in sysfs aren't lost. Thanks, Tomas
Created attachment 435643 [details] take off the lock from complete_cmd_dpc routine The lock for MEGASAS_HW_CRITICAL_ERROR in complete_cmd_dpc routine will not make difference. take it out.
Driver will claim MEGASAS_HW_CRITICAL_ERROR after 3 times OCR can't bring back the controller FW or controller reset can't be success. In complete_cmd_dpc routine, put lock or no lock for the MEGASAS_HW_CRITICAL_ERROR will not make difference. take it out.
(In reply to comment #62) > The lock for MEGASAS_HW_CRITICAL_ERROR in complete_cmd_dpc routine will not > make difference. take it out. Thanks, besides that I was hoping you'll look also at the other places where the locking differs - in megasas_mgmt_ioctl_aen the locking also differs. Please look at this too. Pleas look also at the comment#61 and answer the questions there.
in kernel-2.6.18-210.el5 You can download this test kernel from http://people.redhat.com/jwilson/el5 Detailed testing feedback is always welcomed.
Event posted on 08-03-2010 10:36am JST by moshiro From FJ: We confirmed the PAE kernel works fine. This event sent from IssueTracker by moshiro issue 1000913
Bo, we are still waiting on your reply to comment#61 and #66 Thanks, Tomas
Tomas, Here are the summary why 5.3z don't have the lock, but 5.6 have the lock. in 5.3z --> base 4.01, no MEGASAS_HW_CRITICAL_ERROR check in ioctl and ioctl_aen. in 5.6 ---> base 4.17. the MEGASAS_HW_CRITICAL_ERROR check added to fix some issues between 4.01 to 4.17. Please let me know if we need to port the changes between version 4.01 to 4.17 to 5.3z? Thanks, Bo Yang
Tomas, Here are the summary why 5.3z don't have the MEGASAS_HW_CRITICAL_ERROR check, but 5.6 have the MEGASAS_HW_CRITICAL_ERROR check. in 5.3z --> base 4.01, no MEGASAS_HW_CRITICAL_ERROR check in ioctl and ioctl_aen. in 5.6 ---> base 4.17. the MEGASAS_HW_CRITICAL_ERROR check added to fix some issues between 4.01 to 4.17. Please let me know if we need to port the changes between version 4.01 to 4.17 to 5.3z? Thanks, Bo Yang
(In reply to comment #72) Bo, I wanted to know that the you know about the differences, it is ok now. Please could you reply also on the comment#61 and look at the patch attached there? Thanks
Event posted on 08-19-2010 01:50pm JST by moshiro Comment from FJ regarding each fix request: --- We did test on a 5.6 kernel (210.el5) and confirmed it works OK. Here is the status of each stream. 5.3 hotfix: - Official hotfix provided to Fujitsu. - DONE 5.3.z: - Early errata provided to Fujitsu. - Fujitsu tested and confirmed the early errata works OK. - Fujitsu waiting for the official errata. 5.5.z: - Fujitsu waiting for early errata and/or the official errata. 5.6: - Fujitsu tested and confirmed 210.el5 works OK. Kei Tokunaga --- This event sent from IssueTracker by moshiro issue 1000913
*** Bug 563083 has been marked as a duplicate of this bug. ***
Bo, I think that this part of the patch is wrong: @@ -3432,20 +4209,30 @@ megasas_suspend(struct pci_dev *pdev, pm instance->instancet->disable_intr(instance->reg_set); free_irq(instance->pdev->irq, instance); + scsi_host_put(host); pci_save_state(pdev); pci_disable_device(pdev); The scsi_host_put decrements the host's refcount, I think it makes no sense here. --------------- A similar case is the megasas_resume. When the megasas_resume fails and it is not the root device and then someone wants to rmmod the driver, it ends up calling scsi_host_put(host) in megasas_resume and in megasas_detach_one. Calling scsi_host_put(host) twice seems to be wrong. The same is for calls to pci_free_consistent, I think this is not needed in when the resume fails. Comments?
Tomas, You are right. it is the extra. Thanks,
*** Bug 435698 has been marked as a duplicate of this bug. ***
=== In Red Hat Customer Portal Case 00323953 === --- Comment by Oshiro, Moritoshi on 9/30/2010 5:36 PM --- Hi Bo-san, Fujitsu would like to wait until the code becomes complete and then ask for a test package. Could you please make a test package again once you are done with code cleaning up?
Tomas, Do I need to create a new patch? if yes. Which is the base src? Thanks, Bo Yang
(In reply to comment #83) > > Do I need to create a new patch? if yes. Which is the base src? > If you are asking because of comment#77,78 then not, I created the patch myself. You can download this test kernel from http://people.redhat.com/jwilson/el5
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: A bug was found in the way the megaraid_sas driver (for SAS based RAID controllers) handled physical disks and management IOCTLs (Input/Output Control). All physical disks were exported to the disk layer, allowing an oops in megasas_complete_cmd_dpc() when completing the IOCTL command if a timeout occurred. One possible trigger for this bug was running mkfs. This update resolves this issue by updating the megaraid_sas driver to version 4.31.
*** Bug 499876 has been marked as a duplicate of this bug. ***
This enhancement request was evaluated by the full Red Hat Enterprise Linux team for inclusion in a Red Hat Enterprise Linux minor release. As a result of this evaluation, Red Hat has tentatively approved inclusion of this feature in the next Red Hat Enterprise Linux Update minor release. While it is a goal to include this enhancement in the next minor release of Red Hat Enterprise Linux, the enhancement is not yet committed for inclusion in the next minor release pending the next phase of actual code integration and successful Red Hat and partner testing.
------- Comment From jmtt.com 2010-11-18 21:16 EDT------- This driver was present during my verification of Bug 60123 - [5.6 FEAT] x3690 X5 - Megalon Tracker . That test was conducted on the partner beta drop which contained this version of the driver: [root@elm3a88 lsscsi-0.24b1]# modinfo megaraid_sas filename: /lib/modules/2.6.18-229.el5/kernel/drivers/scsi/megaraid/megaraid_sas.ko description: LSI MegaRAID SAS Driver author: megaraidlinux version: 00.00.04.31-RH1 license: GPL srcversion: D2465CC945888034BE573A9 vermagic: 2.6.18-229.el5 SMP mod_unload gcc-4.1
Verified that megaraid_sas driver (version - 4.31-RH1) is included in RHEL5.6-Snapshot2
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0017.html