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