Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 3 product line. The current stable release is 3.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 154028

Summary: megaraid2 driver causes panic if loaded for a second time
Product: Red Hat Enterprise Linux 3 Reporter: Need Real Name <levent.akyil>
Component: kernelAssignee: Tom Coughlan <coughlan>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: dale.l.busacker, dely.l.sy, jbaron, magdalena.glinkowski, petrides, riel
Target Milestone: ---   
Target Release: ---   
Hardware: ia32e   
OS: Linux   
Whiteboard:
Fixed In Version: RHSA-2006-0144 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-03-15 15:55:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 168424    
Attachments:
Description Flags
This patch is one way to fix the issue
none
modprode, rmmod messages
none
panic output none

Description Need Real Name 2005-04-06 17:03:48 UTC
Description of problem:
In RHEL 3 U3/U4, loading the megaraid2 driver after a rmmod causes kernel 
panic. This was fixed in the older driver (megaraid) but somehow the fix got 
removed in megaraid2 driver. The simple fix is to set the dma_mask to 0xFFFFFF 
before the adapter_query.

How reproducible:
1.insmod megaraid2
2.rmmod megaraid2
3.insmod megaraid2 - will cause a kernel panic

The following fixes the issue.

--- megaraid2.c        2004-08-18 17:33:28.000000000 -0700
+++ megaraid2_new.c 2005-03-31 15:37:53.000000000 -0800
@@ -530,6 +530,8 @@

                did_setup_mbox_f = 1;

+               pci_set_dma_mask(pdev, 0xffffffffULL);
+
                if( mega_query_adapter(adapter) != 0 )
                        goto fail_attach;

Comment 1 Need Real Name 2005-04-06 17:03:49 UTC
Created attachment 112764 [details]
This patch is one way to fix the issue

Comment 7 Jeff Garzik 2005-06-23 21:27:11 UTC
1. -Why- does this fix the problem?  Where is the panic output?

2. Normally the dma_mask is already 0xffffffff, which makes this fix unusual. 
It sounds like something else is going on.

3. Check pci_set_dma_mask() return value, per API.

Comment 8 Tom Coughlan 2005-07-09 00:14:51 UTC
Created attachment 116554 [details]
modprode, rmmod messages

I was not able to reproduce this panic. I tried it a dozen times on an 8 way
i686 with 8 GB of memory with stock U5. IIRC there were no megaraid2 changes
from U4 to U5. See attached for some of the messages. 

Please provide the panic output, and information about your platform, arch, and
megaraid config.

Comment 10 Magdalena Glinkowski 2005-08-03 20:48:44 UTC
This bug is fixed in RHEL 3 U6 early release.

Comment 11 Tom Coughlan 2005-08-10 15:03:31 UTC
There are no changes in the megaraid2 driver betwen U5 and U6 that are likely to
have fixed this. Maybe it was somewhere else. I'll close this now. Re-open if it
comes up again. 

Comment 13 Dale Busacker 2005-09-26 18:50:47 UTC
Created attachment 119269 [details]
panic output

Comment 14 Dale Busacker 2005-09-26 18:53:08 UTC
Reopening...
Since RHEL3 U4 only x86_64 arch is affected.  I have attached the kernel panic 
output.

Additional notes from original submitter:
ââ¦. On the 1st insmod, when mega_i_query is called, the DMA is set to 32 bit 
by default. And pci_map_single() returns expected addresses. After getting 
handles, the DMA mask is set to 64 bit. And normal operation continues.  Ater 
rmmodâing and insmodâing the driver, the same code sequence is executed and 
when we get an address for pci device, we get the SAME address (the same as 
the 1st insmod) and the DMA mask (pdev->dma_mask) is 64 bit. It looks like the 
memory is not being initialized (or the previous values are staying resident) 
so when the driver tries to get DMA handles, it gets 64 bit address (which 
gets truncated etc) which is not valid. â¦â



Comment 15 Ernie Petrides 2005-10-04 02:14:55 UTC
Changing "hardware" field to represent info in last comment.

Comment 17 Tom Coughlan 2005-11-02 00:08:33 UTC
Please test the kernel located at:

http://people.redhat.com/coughlan/.2.4.21-37.7.ELdrvrtest2/

to verify that it solves the problem. 

This contains version v2.10.10.1 of the megaraid2 driver. This is the latest from
LSI Logic and is a candidate for U7. 



Comment 18 Dale Busacker 2005-11-02 22:15:50 UTC
Panic still occurs with this test kernel rpm.  We have made the 
pci_set_dma_mask(pdev, 0xffffffffULL) change mentioned above on this version 
(2.10.10.1) of the driver and it does correct the problem.  

Comment 20 dely.l.sy 2005-11-14 17:53:41 UTC
The patch described in Comment #18 is described in the bug decription above.  
This patch is still needed for version 2.10.10.1.

Comment 21 Ernie Petrides 2005-11-28 23:04:29 UTC
A fix for this problem has just been committed to the RHEL3 U7
patch pool this evening (in kernel version 2.4.21-37.11.EL).


Comment 24 dely.l.sy 2006-01-11 01:44:50 UTC
This issue was fixed in RHEL 3 U7 public beta.  This bugzilla can be closed.

Comment 26 Red Hat Bugzilla 2006-03-15 15:55:15 UTC
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 the 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-2006-0144.html