Message-ID: <1488836928.2870.142.camel@kernel.crashing.org>
Subject: Re: Regression in 4.11 - PowerPC crashes on boot, bisected to
 commit 5657933dbb6e
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Larry Finger <Larry.Finger@lwfinger.net>,
        Bart Van Assche <Bart.VanAssche@sandisk.com>,
        "regressions@leemhuis.info" <regressions@leemhuis.info>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Date: Tue, 07 Mar 2017 08:48:48 +1100
In-Reply-To: <1f134650-adcf-ef11-21aa-fad9d1dc3c29@lwfinger.net>
References: <5bc9c08f-58aa-ef26-8891-4837e2d4184b@lwfinger.net>
         <1488431644.2870.64.camel@kernel.crashing.org>
         <1488823339.3125.3.camel@sandisk.com>
         <1f134650-adcf-ef11-21aa-fad9d1dc3c29@lwfinger.net>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1331
Lines: 34

On Mon, 2017-03-06 at 13:46 -0600, Larry Finger wrote:
> I was able to create a PPC emulation with debian-8.7.1-powerpc-CD-1.iso 
> > following the instructions in https://gmplib.org/~tege/qemu.html. My only 
> problem was that "-net tap" fails and I did not find any way to get networking 
> working.
> 
> After looking at the screen through a number of crashes, I have determined that 
> the top entry in the traceback comes from dmam_alloc_coherent(). I have not been 
> able to see the offset to determine which BUG_ON call in that routine is being 
> triggered.
> 
> I tried to modify panic() to see if I could keep the screen on longer after the 
> failure, but no joy so far.

I think the problem is this code in drivers/macintosh/macio_asic.c:

#ifdef CONFIG_PCI
	/* Set the DMA ops to the ones from the PCI device, this could be
	 * fishy if we didn't know that on PowerMac it's always direct ops
	 * or iommu ops that will work fine
	 *
	 * To get all the fields, copy all archdata
	 */
	dev->ofdev.dev.archdata = chip->lbus.pdev->dev.archdata;
#endif /* CONFIG_PCI */

This is definitely bad. A quick fix is to copy the new dev->dma_ops field
(as well, there is still stuff in archdata that we need too).

A better long term fix is to have a set of macio_dma_ops wrappers that do
"the right thing".

Cheers,
Ben.