Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 146789 - Implement a better solution to the dma memory allocation done in the kernel
Implement a better solution to the dma memory allocation done in the kernel
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
ia32e Linux
high Severity high
: ---
: ---
Assigned To: Larry Woodman
Brian Brock
Depends On:
Blocks: RHEL3U8CanFix
  Show dependency treegraph
Reported: 2005-02-01 12:16 EST by Joshua Giles
Modified: 2007-11-30 17:07 EST (History)
11 users (show)

See Also:
Fixed In Version: RHSA-2006-0437
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-07-20 09:18:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
This is the x86_64-swiotlb.patch that is being referred to here. (2.83 KB, patch)
2005-07-25 16:15 EDT, Larry Woodman
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2006:0437 normal SHIPPED_LIVE Important: Updated kernel packages for Red Hat Enterprise Linux 3 Update 8 2006-07-20 09:11:00 EDT

  None (edit)
Description Joshua Giles 2005-02-01 12:16:27 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET 
CLR 1.1.4322)

Description of problem:
Implement a better solution to the dma memory allocation done in the 
kernel when you have a 32 bit device on a 64bit extended architecture 
OS.  Basically pci_alloc_consistent will have to change.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.  Put a 32bit device (SCSI or RAID device for example) on RHEL 3 
2.  Add stress and wait for a kernel panic

Additional info:
We would like to see this fixed for U5.
Comment 1 Joshua Giles 2005-02-01 12:20:21 EST
A proposed fix from Matt Domsch:

 * Dummy IO MMU functions

void *dma_alloc_coherent(struct device *hwdev, size_t size,
                         dma_addr_t *dma_handle, unsigned gfp)
        void *ret;
        u64 mask;
        int order = get_order(size);

        if (hwdev)
                mask = hwdev->coherent_dma_mask & *hwdev->dma_mask;
                mask = 0xffffffff;
        for (;;) {
                ret = (void *)__get_free_pages(gfp, order);
                if (ret == NULL)
                        return NULL;
                *dma_handle = virt_to_bus(ret);
                if ((*dma_handle & ~mask) == 0)
                free_pages((unsigned long)ret, order);
                if (gfp & GFP_DMA)
                        return NULL;
                gfp |= GFP_DMA;

        memset(ret, 0, size);
        return ret;

So RHEL4 doesn't have quite the same restriction.  When it allocates 
a page, if that page isn't DMA-able by the device, then it frees it 
up and tries again, using the GFP_DMA flag this time.  Because 
generally there are *some* pages available in ZONE_NORMAL that are 
below the 4GB address limit, this works quite well in practice.

The same idea could/should be backported to RHEL3, it's certainly not 
been done yet for the RHEL3 U4 or earlier kernels."
Comment 6 Marty Wesley 2005-05-26 02:46:19 EDT
PM ACK for U6
Comment 10 Larry Woodman 2005-06-10 16:00:28 EDT
Development ACK.  We are waiting for Emulex to verify this works OK for them.

Comment 23 Larry Woodman 2005-07-25 16:15:11 EDT
Created attachment 117134 [details]
This is the x86_64-swiotlb.patch that is being referred to here.
Comment 27 Ernie Petrides 2005-07-27 19:23:01 EDT
Larry Troan, regarding comment #25, this is a RHEL3 bug.  Why is building
the patch into a RHEL4 kernel relevant?
Comment 28 Issue Tracker 2005-07-28 14:05:07 EDT
From User-Agent: XML-RPC

Per Matt....

Finger check.... kenel-2.4.21-32.EL.smp   RHEL3....

This event sent from IssueTracker by ltroan
 issue 73055
Comment 32 Ernie Petrides 2005-08-09 14:00:46 EDT
U6 is closed (and in beta already).
Comment 35 Larry Troan 2005-08-31 10:37:57 EDT
This Bug apparently is not a DUP of Bug 146954 (Engineering's call) but is tied
to to it. 

It is believed that there is a common patch which will resolve both the problems
described here and those described in bug 146954. Both bugs are now public.
Comment 38 Larry Troan 2005-09-19 15:53:56 EDT
Joshua, per Matt's email, can we close this bug since Dell no longer requires a
solution to this problem? 
Comment 39 Larry Troan 2005-09-19 16:13:10 EDT
Clarifying: Dell's solution is for customer's experiencing this problem to
migrate to RHEL4. 
Comment 40 Ernie Petrides 2006-04-19 21:20:18 EDT
A fix for this problem has just been committed to the RHEL3 U8
patch pool this evening (in kernel version 2.4.21-40.7.EL).
Comment 42 Joshua Giles 2006-05-30 11:56:56 EDT
Closing per customer feedback.
*A patch was included that adds the "maxdma" option which will workaround this
Comment 43 Ernie Petrides 2006-05-30 16:23:02 EDT
Reverting to ON_QA after reopening.
Comment 45 Red Hat Bugzilla 2006-07-20 09:18:23 EDT
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.