From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTP id 57C7FDDE06 for ; Sat, 30 Dec 2006 08:53:03 +1100 (EST) Subject: Re: 2.6.20-rc2: kernel BUG at include/asm/dma-mapping.h:110! From: Benjamin Herrenschmidt To: Andreas Schwab In-Reply-To: References: Content-Type: text/plain Date: Sat, 30 Dec 2006 08:52:51 +1100 Message-Id: <1167429171.23340.125.camel@localhost.localdomain> Mime-Version: 1.0 Cc: linuxppc-dev@ozlabs.org, linux1394-devel@lists.sourceforge.net, Stefan Richter , Linux Kernel list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , > Bisecting has identified this commit: > > commit 9b7d9c096dd4e4baacc21b2588662bbb56f36c4e > Author: Stefan Richter > Date: Wed Nov 22 21:44:34 2006 +0100 > > ieee1394: sbp2: convert from PCI DMA to generic DMA > > API conversion without change in functionality > > Signed-off-by: Stefan Richter > > > I'm only seeing this on ppc64, ppc32 seems to be working fine. The patch looks totally bogus to me. It's passing a random struct device from the hbsp host data structure to the dma_map_* routines. which they can't do anything about. The dma_map_* routines only know about some bus types. That's always been the case (that's why you also can't pass a usb device's struct device to them for example). Mostly, PCI, possibly others depending on the platform. So if you are to pass a struct device pointer to dma_map_*, use the one inside the pci_dev of the host. Or have the host driver provide you with the struct device pointer (which is the one from the pci_dev * for PCI implementations, and others give you what they are on, assuming the platform can do dma-* on that device). Ben.