linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Justin T. Gibbs" <gibbs@scsiguy.com>
To: Jens Axboe <axboe@suse.de>
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 12:50:59 -0700	[thread overview]
Message-ID: <200112101950.fBAJoxg54527@aslan.scsiguy.com> (raw)
In-Reply-To: Your message of "Mon, 10 Dec 2001 20:21:30 +0100." <20011210192130.GE12200@suse.de>

>Ok I decided to try and trace this.

...

>		/*
>		 * The sg_count may be larger than nseg if
>		 * a transfer crosses a 32bit page.
>		 */ 
>
>hmm, here it already starts to smell fishy...
>
>		scb->sg_count = 0;
>		while(cur_seg < end_seg) {
>			bus_addr_t addr;
>			bus_size_t len;
>			int consumed;
>
>			addr = sg_dma_address(cur_seg);
>			len = sg_dma_len(cur_seg);
>			consumed = ahc_linux_map_seg(ahc, scb, sg, addr, len);
>
>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.

>	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
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.

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.

--
Justin

  reply	other threads:[~2001-12-10 19:51 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 [this message]
2001-12-10 20:03       ` Jens Axboe
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: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
2001-12-13 21:17               ` Steve Lord

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=200112101950.fBAJoxg54527@aslan.scsiguy.com \
    --to=gibbs@scsiguy.com \
    --cc=LB33JM16@yahoo.com \
    --cc=axboe@suse.de \
    --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;
as well as URLs for NNTP newsgroup(s).