From: Grant Grundler <grundler@parisc-linux.org>
To: Grant Grundler <grundler@parisc-linux.org>
Cc: John David Anglin <dave@hiauly1.hia.nrc.ca>,
linux-parisc@vger.kernel.org
Subject: Re: panic in iommu_is_span_boundary with 32-bit kernel on c3750
Date: Sat, 15 Mar 2008 01:08:53 -0600 [thread overview]
Message-ID: <20080315070853.GC2158@colo.lackof.org> (raw)
In-Reply-To: <20080315070548.GB2158@colo.lackof.org>
On Sat, Mar 15, 2008 at 01:05:48AM -0600, Grant Grundler wrote:
> On Fri, Mar 14, 2008 at 07:31:54PM -0400, John David Anglin wrote:
> > Kyle's tree (vmlinux-2.6.25-rc4-01283-gef95dd8) panics on my c3750 at
> > iommu_is_span_boundary+0x28.
>
> 32-bit or 64-bit kernel?
doh...nm. I finally read the whole subject line (32-bit). :)
Please just ignore that and focus on the rest of the email.
grant
>
> > Looking at the code, I see the panic is
> > caused by a call with r23 = 0. The call is from sba_alloc_range. The
> > actual call appears to be from an inlined copy of sba_search_bitmap.
> > It seems that boundary_size must be 0.
> >
> > Should there be a check in sba_search_bitmap, or is the problem
> > deeper in dma_get_seg_boundary?
>
> I don't expect a deeper problem given this definition:
> static inline unsigned long dma_get_seg_boundary(struct device *dev)
> {
> return dev->dma_parms ?
> dev->dma_parms->segment_boundary_mask : 0xffffffff;
> }
>
> I'm not sure how boundary_size could ever be zero.
> Could this code generate a zero value?
>
> boundary_size = ALIGN(dma_get_seg_boundary(dev) + 1, 1 << IOVP_SHIFT);
> boundary_size >>= IOVP_SHIFT;
>
> I thought ALIGN() would "ROUND_UP()". So it should always be at least 1
> returned.
>
> But in the 32-bit kernel ~0 + 1 == 0 (with overflow).
> Will the ALIGN do the right thing in that case?
> It looks like it will return 0 because of overflow and I think the
> intent is "4GB >> IOVP_SHIFT" (so 20 bits, ie 1MB).
> Maybe we want dma_get_seg_boundary() to deal with the ALIGN and other stuff
> so it just returns a PAGE_SIZE count?
>
> A simple test before assigning boundary_size would be to check
> "dev->dma_parms". If dev->dma_parms is zero, just return 1 << 20
> and see if that works for you.
>
> But I'm pretty tired right now (long week) and I can't wrap my brain
> around the bit flipping. Would be good if someone else confirmed.
>
> cheers,
> grant
>
> >
> > Dave
> > --
> > J. David Anglin dave.anglin@nrc-cnrc.gc.ca
> > National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2008-03-15 7:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-14 23:31 panic in iommu_is_span_boundary with 32-bit kernel on c3750 John David Anglin
2008-03-15 7:05 ` Grant Grundler
2008-03-15 7:08 ` Grant Grundler [this message]
2008-03-15 12:01 ` rubisher
2008-03-16 14:29 ` John David Anglin
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=20080315070853.GC2158@colo.lackof.org \
--to=grundler@parisc-linux.org \
--cc=dave@hiauly1.hia.nrc.ca \
--cc=linux-parisc@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.