mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Sven Schnelle <svens@stackframe.org>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	Joerg Roedel <joerg.roedel@amd.com>, Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org
Subject: Re: swiotlb_alloc_coherent: allocated memory is out of range for device
Date: Wed, 22 Oct 2008 13:07:53 +0200	[thread overview]
Message-ID: <s5hprlsnb06.wl%tiwai@suse.de> (raw)
In-Reply-To: <s5htzb4nbnd.wl%tiwai@suse.de>

At Wed, 22 Oct 2008 12:53:58 +0200,
I wrote:
> 
> At Sun, 19 Oct 2008 12:09:32 +0200,
> Sven Schnelle wrote:
> > 
> > Hi List,
> > 
> > my kernel dies while probing parport with the following last words:
> > 
> > [    3.672199] parport_pc 00:0b: reported by Plug and Play ACPI
> > [    3.677969] parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA]
> > [    3.687691] hwdev DMA mask = 0x0000000000ffffff, dev_addr = 0x0000000020000000
> > [    3.694916] Kernel panic - not syncing: swiotlb_alloc_coherent: allocated memory is out of range for device
> > 
> > I haven't started a bisection yet, but this seems to be introduced
> > somewhere between 2.6.26 and 2.6.27, at least 2.6.26 was working without
> > problems. The dmesg log + config was obtained from a kernel compiled
> > from git on 10/16/2008.
> 
> This bug hits me, too.  Looks like swiotlb assumes that the alloc caller
> must set GFP_DMA appropriately by itself since GFP_DMA hack was
> removed.  The patch below should fix this particular case.
> 
> HOWEVER: the fundamental problem appears to be in swiotlb itself.
> It assumes that iotlb pages are in DMA area.  But, in this case, the
> driver sets 24bit DMA (as of PnP) while iotlb pages are allocated 
> under 32bit DMA via alloc_bootmem_low_pages().  This doesn't work, of
> course.
> 
> So, even adding GFP_DMA works mostly, it has still potentially
> breakage when you can't get the page and fall back to iotlb pages,
> just like the panic above.
> 
> Also, the removal of GFP_DMA hack is a bad idea.  For example, if a
> device requires 28bit DMA mask, it doesn't set always GFP_DMA for
> allocation because pages in ZONE_NORMAL may be inside that DMA mask.
> Normal allocators allow this behavior but swiotlb allocator doesn't.
> (Correct me if I'm wrong here -- I haven't followed much the recent
>  changes.)

The patch below is to a workaround for that.


Takashi

diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index f8eebd4..cb20149 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -468,6 +468,7 @@ swiotlb_alloc_coherent(struct device *hwdev, size_t size,
 	void *ret;
 	int order = get_order(size);
 
+ again:
 	ret = (void *)__get_free_pages(flags, order);
 	if (ret && address_needs_mapping(hwdev, virt_to_bus(ret), size)) {
 		/*
@@ -478,6 +479,10 @@ swiotlb_alloc_coherent(struct device *hwdev, size_t size,
 		ret = NULL;
 	}
 	if (!ret) {
+		if (!(flags & __GFP_DMA)) {
+			flags |= __GFP_DMA;
+			goto again;
+		}
 		/*
 		 * We are either out of memory or the device can't DMA
 		 * to GFP_DMA memory; fall back on

  reply	other threads:[~2008-10-22 11:08 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-19 10:09 Sven Schnelle
2008-10-22 10:53 ` Takashi Iwai
2008-10-22 11:07   ` Takashi Iwai [this message]
2008-10-22 11:29   ` FUJITA Tomonori
2008-10-22 12:06     ` Takashi Iwai
2008-10-22 13:13       ` FUJITA Tomonori
2008-10-22 13:19         ` FUJITA Tomonori
2008-10-22 13:32         ` Takashi Iwai
2008-10-23  2:36           ` FUJITA Tomonori
2008-10-23  5:22             ` Takashi Iwai
2008-10-23 11:58               ` Takashi Iwai
2008-10-23 10:15                 ` Ingo Molnar
2008-10-23 11:46                   ` FUJITA Tomonori
2008-10-28 10:36                   ` Takashi Iwai
2008-10-28 10:39                     ` Ingo Molnar
2008-10-28 10:47                       ` Takashi Iwai

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=s5hprlsnb06.wl%tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=joerg.roedel@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=svens@stackframe.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

all inboxes | Powered by JetHome®