Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754544AbYJVLIH (ORCPT ); Wed, 22 Oct 2008 07:08:07 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752520AbYJVLHz (ORCPT ); Wed, 22 Oct 2008 07:07:55 -0400 Received: from mx2.suse.de ([195.135.220.15]:45411 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752143AbYJVLHy (ORCPT ); Wed, 22 Oct 2008 07:07:54 -0400 Date: Wed, 22 Oct 2008 13:07:53 +0200 Message-ID: From: Takashi Iwai To: Sven Schnelle Cc: FUJITA Tomonori , Joerg Roedel , Ingo Molnar , linux-kernel@vger.kernel.org Subject: Re: swiotlb_alloc_coherent: allocated memory is out of range for device In-Reply-To: References: <87d4hwuc9v.fsf@apollo.stackframe.org> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.3 (x86_64-suse-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2828 Lines: 74 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/