All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@hp.com>
To: Emoore@lsil.com
Cc: linux-scsi@vger.kernel.org, linux-ia64@vger.kernel.org
Subject: mpt sets 64bit consistent mask yet requires mapping in same 4GB
Date: Fri, 13 Feb 2004 16:12:05 +0000	[thread overview]
Message-ID: <1076688724.2462.16.camel@patsy.fc.hp.com> (raw)

Eric,

   I think I found a bug in the version 3.00.02 mpt driver that's
currently in Linus' 2.6 tree (latest linux-2.5).  Here's the code
snippet:

message/fusion/mptbase.c: PrimeIocFifos()
...
    if (sizeof(dma_addr_t) = sizeof(u64)) {
        /* Check: upper 32-bits of the request and reply frame
         * physical addresses must be the same.
         */
        if (((u64)ioc->req_frames_dma >> 32) != ((u64)ioc->reply_frames_dma >> 32)){
            goto out_fail;
    }

req_frames_dma and reply_frames_dma are aligned version of dma addresses
retrieved via two separate pci_alloc_consistent() calls.  The mpt driver
sets a 64bit consistent dma mask.  How is it reasonable to assume two
separate mappings will fall within the same 4GB chunk of memory?  I
recently added support for consistent mapping bypass in the sba_iommu
driver for the ia64 zx1 chipset.  Randomly on bootup, the MPT driver
fails.  Checking the mappings, I get a things like this:

mptbase: Initiating ioc0 bringup
ioc0: 53C1030: Capabilities={Initiator}
sba_alloc_coherent() bypassing, dma_handle: 0x1fffb8000, addr: 0xe0000001fffb8000
sba_alloc_coherent() bypassing, dma_handle: 0x40ffcd8000, addr: 0xe0000040ffcd8000
PrimeIocFifos() req_frames_dma: 0x40ffcd8000, reply_frames_dma: 0x1fffb8000
mptbase: WARNING - ioc0 did not initialize properly! (-3)

These are two perfectly valid consistent mappings as far as the platform
code is concerned.  I think mpt really needs to either set a 32bit
consistent map of do a single allocation when it requires this type of
thing.  Thanks,

	Alex

-- 
Alex Williamson                             HP Linux & Open Source Lab


WARNING: multiple messages have this Message-ID (diff)
From: Alex Williamson <alex.williamson@hp.com>
To: Emoore@lsil.com
Cc: linux-scsi@vger.kernel.org, linux-ia64@vger.kernel.org
Subject: mpt sets 64bit consistent mask yet requires mapping in same 4GB chunk?!?
Date: Fri, 13 Feb 2004 09:12:05 -0700	[thread overview]
Message-ID: <1076688724.2462.16.camel@patsy.fc.hp.com> (raw)

Eric,

   I think I found a bug in the version 3.00.02 mpt driver that's
currently in Linus' 2.6 tree (latest linux-2.5).  Here's the code
snippet:

message/fusion/mptbase.c: PrimeIocFifos()
...
    if (sizeof(dma_addr_t) == sizeof(u64)) {
        /* Check: upper 32-bits of the request and reply frame
         * physical addresses must be the same.
         */
        if (((u64)ioc->req_frames_dma >> 32) != ((u64)ioc->reply_frames_dma >> 32)){
            goto out_fail;
    }

req_frames_dma and reply_frames_dma are aligned version of dma addresses
retrieved via two separate pci_alloc_consistent() calls.  The mpt driver
sets a 64bit consistent dma mask.  How is it reasonable to assume two
separate mappings will fall within the same 4GB chunk of memory?  I
recently added support for consistent mapping bypass in the sba_iommu
driver for the ia64 zx1 chipset.  Randomly on bootup, the MPT driver
fails.  Checking the mappings, I get a things like this:

mptbase: Initiating ioc0 bringup
ioc0: 53C1030: Capabilities={Initiator}
sba_alloc_coherent() bypassing, dma_handle: 0x1fffb8000, addr: 0xe0000001fffb8000
sba_alloc_coherent() bypassing, dma_handle: 0x40ffcd8000, addr: 0xe0000040ffcd8000
PrimeIocFifos() req_frames_dma: 0x40ffcd8000, reply_frames_dma: 0x1fffb8000
mptbase: WARNING - ioc0 did not initialize properly! (-3)

These are two perfectly valid consistent mappings as far as the platform
code is concerned.  I think mpt really needs to either set a 32bit
consistent map of do a single allocation when it requires this type of
thing.  Thanks,

	Alex

-- 
Alex Williamson                             HP Linux & Open Source Lab


             reply	other threads:[~2004-02-13 16:12 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-13 16:12 Alex Williamson [this message]
2004-02-13 16:12 ` mpt sets 64bit consistent mask yet requires mapping in same 4GB chunk?!? Alex Williamson
2004-02-13 21:20 ` mpt sets 64bit consistent mask yet requires mapping in same 4 Moore, Eric Dean
2004-02-13 21:20   ` mpt sets 64bit consistent mask yet requires mapping in same 4 GB chunk?!? Moore, Eric Dean
2004-02-13 21:30   ` Jesse Barnes
2004-02-13 21:30     ` Jesse Barnes
2004-02-13 22:52     ` Bjorn Helgaas
2004-02-13 22:52       ` Bjorn Helgaas
2004-02-13 23:08       ` Jeremy Higdon
2004-02-13 23:08         ` Jeremy Higdon
2004-02-13 23:13       ` Matthew Wilcox
2004-02-13 23:39         ` Jeremy Higdon
2004-02-13 23:39           ` Jeremy Higdon
2004-02-13 23:23 ` mpt sets 64bit consistent mask yet requires mapping in same 4 Moore, Eric Dean
2004-02-13 23:23   ` mpt sets 64bit consistent mask yet requires mapping in same 4 GB chunk?!? Moore, Eric Dean

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1076688724.2462.16.camel@patsy.fc.hp.com \
    --to=alex.williamson@hp.com \
    --cc=Emoore@lsil.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.