All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: "Justin T. Gibbs" <gibbs@scsiguy.com>
Cc: LBJM <LB33JM16@yahoo.com>, linux-kernel@vger.kernel.org
Subject: Re: highmem, aic7xxx, and vfat: too few segs for dma mapping
Date: Mon, 10 Dec 2001 21:03:02 +0100	[thread overview]
Message-ID: <20011210200302.GA13498@suse.de> (raw)
In-Reply-To: <20011210192130.GE12200@suse.de> <200112101950.fBAJoxg54527@aslan.scsiguy.com>
In-Reply-To: <200112101950.fBAJoxg54527@aslan.scsiguy.com>

On Mon, Dec 10 2001, Justin T. Gibbs wrote:
> >ahc_linux_map_seg checks if scb->sg_count gets bigger than AHC_NSEG, in
> >fact the test is
> >
> >	if (scb->sg_count + 1 > AHC_NSEC)
> >		panic()
> >
> >What am I missing here?? I see nothing preventing hitting this panic in
> >some circumstances.
> 
> If you don't cross a 4GB boundary, this is the same as a static test
> that you never have more than AHC_NSEG segments.

Yes sorry, my one-off.

> >	if (scb->sg_count + 2 > AHC_NSEG)
> >		panic()
> >
> >weee, we crossed a 4gb boundary and suddenly we have bigger problems
> >yet. Ok, so what I think the deal is here is that AHC_NSEG are two
> >different things to your driver and the mid layer.
> >
> >Am I missing something? It can't be this obvious.
> 
> You will never cross a 4GB boundary on a machine with only 2GB of
> physical memory.  This report and another I have received are for

Of course not.

> configurations with 2GB or less memory.  This is not the cause of the
> problem.  Further, after this code was written, David Miller made the
> comment that an I/O that crosses a 4GB boundary will never be generated
> for the exact same reason that this check is included in the aic7xxx
> driver - you can't cross a 4GB page in a single PCI DAC transaction.  
> I should go verify that this is really the case in recent 2.4.X kernels.

Right, we decided against ever doing that. In fact I added the very code
to do this in the block-highmem series -- however, this assumption
breaks down in the current 2.4 afair on 64-bit archs.

> Saying that AHC_NSEG and the segment count exported to the mid-layer are
> too differnt things is true to some extent, but if the 4GB rule is not
> honored by the mid-layer implicitly, I would have to tell the mid-layer
> I can only handle half the number of segments I really can.  This isn't
> good for the memory footprint of the driver.  The test was added to
> protect against a situation that I don't believe can now happen in Linux.

> In truth, the solution to these kinds of problems is to export alignment,
> boundary, and range restrictions on memory mappings from the device
> driver to the layer creating the mappings.  This is the only way to
> generically allow a device driver to export a true segment limit.

I agree, and that is why I've already included code to do just that in
2.5.

-- 
Jens Axboe


  reply	other threads:[~2001-12-10 20:04 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-10  1:32 highmem, aic7xxx, and vfat: too few segs for dma mapping LBJM
2001-12-10 18:40 ` Justin T. Gibbs
2001-12-10 19:21   ` Jens Axboe
2001-12-10 19:50     ` Justin T. Gibbs
2001-12-10 20:03       ` Jens Axboe [this message]
2001-12-10 19:21         ` Gérard Roudier
2001-12-11  6:12           ` David S. Miller
2001-12-11 17:01             ` Gérard Roudier
2001-12-12  9:36               ` Jens Axboe
2001-12-12 13:32                 ` Andrea Arcangeli
2001-12-12 17:22                   ` Gérard Roudier
2001-12-12 22:19                     ` Andrea Arcangeli
2001-12-12 20:24                       ` Gérard Roudier
2001-12-13  0:26                         ` David S. Miller
2001-12-13 16:17                           ` Gérard Roudier
2001-12-13 20:30                             ` David S. Miller
2001-12-13 18:13                               ` Gérard Roudier
2001-12-13  0:06                     ` David S. Miller
2001-12-13 16:39                       ` Gérard Roudier
2001-12-12 16:39                 ` Gérard Roudier
2001-12-13 20:10       ` Steve Lord
2001-12-13 20:15         ` Justin T. Gibbs
2001-12-13 20:29           ` Steve Lord
2001-12-13 20:48             ` Justin T. Gibbs
2001-12-13 20:58               ` Steve Lord
2001-12-13 21:17                 ` Steve Lord
2001-12-13 21:27                   ` David S. Miller
2001-12-14 15:16                     ` Jens Axboe
2001-12-14 16:15                       ` Jens Axboe
2001-12-14 16:22                         ` Alok K. Dhir
2001-12-14 16:32                           ` Jens Axboe
2001-12-14 16:25                         ` Stephen Lord
2001-12-14 16:24                           ` Jens Axboe

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=20011210200302.GA13498@suse.de \
    --to=axboe@suse.de \
    --cc=LB33JM16@yahoo.com \
    --cc=gibbs@scsiguy.com \
    --cc=linux-kernel@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.