Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 154028 - megaraid2 driver causes panic if loaded for a second time
Summary: megaraid2 driver causes panic if loaded for a second time
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel
Version: 3.0
Hardware: ia32e
OS: Linux
Target Milestone: ---
Assignee: Tom Coughlan
QA Contact: Brian Brock
Depends On:
Blocks: 168424
TreeView+ depends on / blocked
Reported: 2005-04-06 17:03 UTC by Need Real Name
Modified: 2007-11-30 22:07 UTC (History)
6 users (show)

Fixed In Version: RHSA-2006-0144
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-03-15 15:55:12 UTC
Target Upstream Version:

Attachments (Terms of Use)
This patch is one way to fix the issue (deleted)
2005-04-06 17:03 UTC, Need Real Name
no flags Details | Diff
modprode, rmmod messages (deleted)
2005-07-09 00:14 UTC, Tom Coughlan
no flags Details
panic output (deleted)
2005-09-26 18:50 UTC, Dale Busacker
no flags Details

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2006:0144 qe-ready SHIPPED_LIVE Moderate: Updated kernel packages available for Red Hat Enterprise Linux 3 Update 7 2006-03-15 05:00:00 UTC

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
Since RHEL3 U4 only x86_64 arch is affected.  I have attached the kernel panic 

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:

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 
( of the driver and it does correct the problem.  

Comment 20 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

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 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.

Note You need to log in before you can comment on or make changes to this bug.