Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie

From: "Michel Dänzer" <michel@daenzer.net>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Tony Breeds <tbreeds@au1.ibm.com>, acrux <acrux_it@libero.it>,
	dri-devel@lists.freedesktop.org
Subject: Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie
Date: Thu, 16 Feb 2012 09:26:06 +0100	[thread overview]
Message-ID: <1329380766.2859.397.camel@thor.local> (raw)
In-Reply-To: <1329379371.2892.7.camel@pasglop>

On Don, 2012-02-16 at 19:02 +1100, Benjamin Herrenschmidt wrote: 
> On Thu, 2012-02-16 at 08:50 +0100, Michel Dänzer wrote:
> > > > The second case with no firmware is a bit more surprising, looks like
> > > > something bad happened on the PCI express bus or the kernel tried to
> > > > access something that the card rejected (target abort or PCIe
> > > > equivalent most likely), thus triggering a PLB error . That could be
> > > > investigated a bit more.
> > 
> > AFAICT in both cases the immediate problem is the PLB error on first
> > access to VRAM, indicating some kind of problem with ioremap_wc() or
> > generally PCIe device memory access.
> 
> I think the problem here is more along the lines of >32-bit physical
> memory and ttm screwing up the physical addresses before mapping the
> vram object.
> 
> Tony (CC) has some patches to address that part (for use with a 476
> which is cache coherent, we got evergreen working on that).
> 
> I think he hasn't yet "polished" the patches enough (ie fixed all the
> drivers for the change in types) but basically, quite a few places in
> there need to store physical addresses in resource_size_t instead of
> long's.

I see, thanks.

> > > Anyway after nearly ten years, due a lack in resources, i'm sadly going
> > > to suspend the CRUX PPC project and my activism pro free
> > > software thus i'm unable to follow these debug. I'll hold on to me
> > > the only YDL Powerstation then from the next weeks i'll can only follow
> > > trying to help in debug [1] on this specific machine.  
> > > 
> > > [1]http://lists.freedesktop.org/archives/dri-devel/2012-January/018575.html
> > 
> > For that one, I'd try adding some more debugging output to
> > radeon_get_bios() to find out which method it ends up using to retrieve
> > the ROM contents, and why it doesn't look like it's an ATOM BIOS.
> 
> Is it an Apple card or an x86 card ? Apple cards don't have the BIOS in
> the right place unfortunately.

I don't think there ever were any Mac Editions of FireGL cards, and if
it wasn't an x86 card, I'd expect different error messages.

-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel