Linux PARISC architecture development
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox