From: Luca <kronos.it@gmail.com>
To: "Jay L. T. Cornwall" <jay@esuna.co.uk>
Cc: "Jay Cliburn" <jacliburn@bellsouth.net>,
linux-kernel@vger.kernel.org, "Chris Snook" <csnook@redhat.com>,
"huang xiong" <xiong.huang@atheros.com>
Subject: Re: Attansic L1 page corruption (was: 2.6.22-rc5: pdflush oops under heavy disk load)
Date: Mon, 25 Jun 2007 14:58:14 +0200 [thread overview]
Message-ID: <68676e00706250558o36ee5a63je3aa0ba36e8a162@mail.gmail.com> (raw)
In-Reply-To: <467FB237.2030703@esuna.co.uk>
On 6/25/07, Jay L. T. Cornwall <jay@esuna.co.uk> wrote:
> Jay Cliburn wrote:
>
> > For reasons not yet clear to me, it appears the L1 driver has a bug or
> > the device itself has trouble with DMA in high memory. This patch,
> > drafted by Luca Tettamanti, is being explored as a workaround. I'd be
> > interested to know if it fixes your problem.
>
> Yes, it certainly seems to. Now running with this patch and 4GB active,
> I've transferred about 15GB with no problem so far. It usually oopses
> after a GB or two.
>
> I guess it's not an ideal solution, architecturally speaking, but it's a
> good deal better than an unstable driver.
It may cause a "bounce" (i.e. data is copied to another buffer in
lower memory) when a skb is allocated in high memory. Furthermore - at
least on AMD systems - it should be possible to use the IOMMU to remap
the memory to a bus address < 4GB.
Xiong can you comment on this issue? To recap: users are seeing hard
locks when L1 driver does a DMA to/from a high memory area (physical
address > 4GB). Limiting DMA to the lower 4GB with:
pci_set_dma_mask(pdev, DMA_32BIT_MASK);
cures the issue. Does L1 have any know problem decoding 64 addresses?
Luca
next prev parent reply other threads:[~2007-06-25 12:58 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-22 0:07 2.6.22-rc5: pdflush oops under heavy disk load Jay L. T. Cornwall
2007-06-22 14:47 ` Chuck Ebbert
2007-06-22 15:04 ` Jay L. T. Cornwall
2007-06-23 12:14 ` Jay L. T. Cornwall
2007-06-23 17:23 ` Andrew Morton
2007-06-24 9:57 ` (Last oops is Tainted: P) " Oleg Verych
2007-06-24 10:10 ` Jay L. T. Cornwall
2007-06-24 10:57 ` Oleg Verych
2007-06-24 17:59 ` Jay Cliburn
2007-06-24 20:31 ` Jay L. T. Cornwall
2007-06-24 21:45 ` Jay Cliburn
2007-06-25 12:16 ` Attansic L1 page corruption (was: 2.6.22-rc5: pdflush oops under heavy disk load) Jay L. T. Cornwall
2007-06-25 12:42 ` Attansic L1 page corruption Jay Cliburn
2007-06-25 21:18 ` [PATCH] atl1: disable 64bit DMA Luca Tettamanti
2007-06-25 21:36 ` Chris Snook
2007-06-25 21:51 ` Jay L. T. Cornwall
2007-06-25 21:57 ` Chris Snook
2007-06-25 23:00 ` Jay Cliburn
2007-06-25 23:17 ` Jeff Garzik
2007-06-25 23:40 ` Chris Snook
2007-06-26 21:12 ` Luca
2007-06-27 0:16 ` Jay Cliburn
2007-06-25 12:58 ` Luca [this message]
2007-06-24 22:51 ` 2.6.22-rc5: pdflush oops under heavy disk load Jesper Juhl
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=68676e00706250558o36ee5a63je3aa0ba36e8a162@mail.gmail.com \
--to=kronos.it@gmail.com \
--cc=csnook@redhat.com \
--cc=jacliburn@bellsouth.net \
--cc=jay@esuna.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=xiong.huang@atheros.com \
/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
all inboxes | Powered by JetHome®